Story of a Commodore 64

Almost any object can become part of a certain story. This is the story of an old Commodore 64 (8 bits computer) I got for a few dollars here in Buenos Aires. The computers was not working so this is the story of how I found the parts needed to take it back to life.

In part of my spare time I enjoy working on electronics and with nowadays is called “maker culture” and more particularly with retro-computing.
When I was a kid my first computer was a Radio Shack Color Computer II (known as coco 2). I was lucky to get that computer. At that time it gave me lot of fun and excitement. Coco was just great. Still I keep that coco with me, and is working just fine as in the old days. Of course today, it is mostly useless as you can not search the web, or even use a fancy spreadsheet.
I remember Linus Torvalds’ opinion on 8 bit computers: At those days if you had enough documentation and curiosity you could develop a good knowledge about how a computer works. Because computers were simpler than the ones that came after. That is part of the success of a computer like Raspberry Pi.
I think we can still learn a lot of those old computers. It’s just like going to a museum, but a particular one where you can play around
with objects.
Some months ago I got a Commodore 64 for a few argentine pesos. The reason why? The computer did not work. The outside was good, keyboard looked fine, case was in good shape too, but there was no video output and the power supply had been lost. No video, no power supply.
I wondered if I should have removed the pcb and put a raspberry Pi in it, but I decided first to try to repair the commodore and to get or build a power supply.

The cause of the video failure (no video at all/black screen) was the MOS-8701 chip. The chip had to be replaced, and finding one of them nowadays is not easy.

Fortunately, I was able to find a new one. The price was not cheap, but at that point I was committed to get the C64 repaired.

Then, I went to a the house of a friend of mine who owns a c64 and tested mine. With the new 8701 it was working.
Now it was necessary to get or build a power supply. C64 original PSU it was its weakest part. The power supply used to get very hot, and I mean very hot. It was placed inside a dust proof case and that contributed to the increasing heat.
So building a modern power supply using a switching psu would be fine. With parts I have lying around the house: a case, a switching 5 Vdc power supply and a transformer for 9 Vac. Finding a DIN plug the C64 uses for PSU was not easy nowadays. I almost gave up, but finally I could get one. Otherwise I would have had to order it abroad.
I put those parts inside the case, added a 2A fuse for the 9 Vac output. Tested the voltages and the DIN pinout twice, and then plugged into the C64.
The computer is working as in the old days. Now is time to get some games and show the kids how we had fun time ago.

In this video C64 and it "brand new" psu can be seen working:

-RetuX-
Continuar »

Una historia retro (computación)

Casi cualquier objeto puede convertirse en una historia. Cosas incluso con poco o nulo valor de cambio pueden tener un enorme valor de uso para alguien. Los que amamos ciertos objetos, aún más allá de las posibilidades de nuestro espacio en casa lo sabemos bien.
Esta es la historia de una Commodore 64.

A más o menos 30 años de su punto de mayor suceso en el mercado la conseguí por unos pocos pesos. Claro, no funcionaba y tampoco tenía fuente de alimentación. Lento trabajo y diversión de fin de semana, ayuda de amigos y un poco de cabezadurismo per jodere y la C64 está en funcionamiento otra vez.


Linus Torvalds se refería a las computadoras de la era de los 8 bits de una manera, me parece, muy acertada: bastaba que tuvieras acceso a la documentación e información para que desarrollaras conocimiento con y acerca de esas máquinas. No es casual que varios desarrolladores del kernel Linux sean aficionados fervientes del retro computing, quizá el caso más conocido sea el de John Linville.
Tampoco es casual el éxito de las Raspberry Pi. Dejen que sean populares y si los chicos se interesan de verdad seguramente las aprovechen. Cuanto más básica es una herramienta más necesitas desarrollar una habilidad con ella.
Creo que tantos años después sin duda alguna nostalgia cabe: tener una C64 en la Argentina de aquel tiempo era algo que no todos podíamos tener. Sin no me equivoco, fue algún aristócrata europeo el que dijo, la principal diferencia entre un hombre y un niño es el precio de sus juguetes.
Fue así: a fines de 2016 conseguí por unos pocos pesos esta Commodore 64, en buen estado externo pero sin funcionar

.
El bajo precio se justificaba porque la máquina no funcionaba, y además se le había perdido o destruido la fuente de alimentación original.
Con la ayuda de mi amigo Hernán y Alejandro -con los que desde la secundaria nos hicimos todos radioaficionados- hicimos el troubleshooting básico: pudimos detectar por qué la máquina no generaba señal de video. El chip MOS-8701 era el responsable.

Conseguirlo fue providencial. No creo que hoy en día se use ese integrado para alguna otra cosa supongo, así que me hipótesis es que habrá quedado en stock desde los años '90.
Reemplazado el chip había que encontrar una fuente de alimentación. La fuente de alimentación original de la C64 era su talón de Aquiles. Era una caja estanca que calentaba por los cuatro costados. Recuerdo un amigo de la primaria que la tenía sobre una alfombra. Un milagro que de jugar al Moon Patrol no hayamos prendido fuego la alfombra.

Esquemático de la fuente original

La fuente original era muy básica. Por supuesto no era switching, lo que hacía que fuera mucho menos eficaz. Pero eso era lo habitual para la época.
Quizá lo más revolucionario que tuvo la Apple II, primera computadora masiva de Apple fue que fue la primera en contar con una fuente switching. Era algo que la hacía cara, pero era revolucionario para cuando esa máquina salió al mercado.
El resto de las computadoras similares, no la tenía.
Entonces lo más fácil en el siglo XXI era armar un gabinete con una fuente switching y un transformador convencional para la salida de 9 VAC.
La fuente switching vino de algún switch de red que no sirvió más. Y el trafo, lo compré ex profeso. El gabinete también había pertenecido a alguna fuente y lo había guardado pensando usarlo alguna vez.

Agregué un fusible a los 9VAC (de 2A) ya que la switching provee bastante protección.

Y esa es la historia de esta C64. La fuente funcionando puede verse acá:


Continuar »

conky se integra cada vez mejor con KDE Plasma

Desde que usaba fluxbox como window manager en una vieja notebook Pentium III durante los primeros años 2000 siempre me gustó conky o su antecesor, torsmo.

En la mayoría de los ambientes de escritorio conky se integraba sin problemas. Con KDE lo hacía interfiriendo un poco con los widgets nativos y modificando un poco el comportamiento general del escritorio. Creo que esos días pasaron para siempre. Por lo menos ahora estoy super conforme con cómo conky se integró con Plasma.

Recientemente también conky cambió la forma en que la configuración (en general el archivo ~/.conkyrc) debe estar estructurada. La configuración que venía usando, que se puede ver en la imagen está disponible en este repo:

https://github.com/retux/conky-configs

Una breve guía sobre cómo instalarlo se puede leer en el README.

¿Cómo optimizar la configuració con Plasma?

La clave de esto la encontré por algún foro que ahora no puedo encontrar su url, pero se trata de lo siguiente:

Verán en el archivo de configuración la definición del tipo de ventana para conky es:

own_window_type = 'dock'

Bueno, esto hará la magia. Lo que debemos configurar es el comportamiento que deseamos para esa ventana, lo que en Plasma se hace de esta forma:

Fíjense que el nombre que le demos a la ventana, en este caso 'conky' es significativo. Con eso debe bastar, desde luego hay que ajustar las preferencias en la sección de texto del .conkyrc para que reflejen las características de su equipo.


Continuar »

Proyecto de fin de semana: Usar una fuente ATX como fuente para Lab con termostato (opcional)

Las fuentes ATX genéricas son relativamente económicas y tienen múltiples ventajas: ofrecen una variedad de tensiones de salida con corrientes generosas. 3,3v; 5v, 12V entre otras tensiones de salida sirven para tener una buena fuente de laboratorio con salidas estabilizadas y bien filtradas.

Ideal para probar cualquier circuito digital. A continuación sigue un proyecto muy simple: modificar una fuente ATX genérica y además con un agregado opcional: si no queremos que el cooler funcione constantemente se usa un termostato simple, que encenderá el ventilador cuando la temperatura interna sea superior a los 30° aproximadamente.

En la secundaria, el Cuba del barrio de Belgrano, uno de los primeros trabajos prácticos del taller de electrónica consistía en construir una fuente de alimentación variable de 2-30v. Se empezaba en primer año, en el taller de hojalatería, armando el gabinete de chapa rígida.
Durante un bimestre de segundo año, creo, se mandaba a bobinar el transformador, y con todos los componentes listos, la armábamos. Todavía la conservo y sigue andando muy bien.
La contra de las fuentes como aquella, básicamente es que por no ser switching son muy pesadas. El Apple II fue la primera computadora en tener una fuente switching a fines de los '70 y en aquel tiempo debía resultar muy costoso, pero en términos de "usabilidad" aquella máquina debía pesar menos de la tercera parte de sus competidoras que no usaban fuente switching.
Hoy en día es muy sencillo y relativamente económico encontrar una fuente de tensiones múltiples, con buen filtrado y estabilización: cualquier fuente ATX de PC.

Fuente ATX para Lab, con termostato (opcional)

Este fin de semana me hice de un rato para divertirme adaptando una fuente ATX. Mi idea inicial era la siguiente: precisaba una fuente de 5Vcc con por los menos 2A, para alimentar en simultáneo varias Raspberry Pi que están dando vueltas por ahí. Una de ellas tiene un disco duro que también requiere +12Vcc. Con una fuente que continuamente esté disponible también aprovecharía los 5Vcc para colgar un hub USB que sirviera de cargador para la mayoría de los celulares de la familia.
Además uno de mis TOCs es que no me gustan los coolers. Son necesarios lo sé, pero hacen ruido. Por eso pensé agregarle un termostato a esta fuente modificada. El cooler solo se encendería cuando el calor en el interior fuera superior a cierto umbral.

Para poder conectar todo fácilmente se puede usar una bornera. Yo agregué también una DIN/Canon para usar para la salida para las raspberries.

Una vez hecho eso, hay que cortar los cables y conectarlos uno a uno a la bornera y soldar en la ficha canon. El código de colores usado para identificar las tensiones en las PSU ATX puede encontrarse aquí: http://www.instructables.com/id/A-Makers-Guide-to-ATX-Power-Supplies/step2/Wire-Colors-Functions-in-the-PSU/

Si fuéramos a usar la fuente para un Lab, para probar circuitos o proyectos, con la bornera creo que estaría más que suficiente. Decidí agregar un pequeño termostato, que es un circuito muy similar al que se ve acá: http://www.craig.copperleife.com/tech/thermo/
Basado en un opercacional LM741 como transistor usé un BD140. Entro colector y emisor va a circular la corriente que impulsa el cooler, una vez que la temperatura supere la que se haya calibrado. El termostato es muy simple y con los valores usados sirve para accionarse entre los 25-35 grados centígrados.

Acá se puede ver el termostato ya montado. Hablando eléctricamente, dentro de la fuente el ambiente es muy ruidoso. Pensé que el ruido volvería loco al 741, pero por suerte se comportó de diez.

Así es como quedó una vez cerrado el gabinete.

Es un proyecto simple y creo que útil.

Pero ATENCIÓN con esta advertencia:

Las fuentes switching funcionan con tensiones muy elevadas por eso su manipulación es riesgosa. Por eso hay que tener mucha precaución incluso aunque hayamos desconectado la fuente de los 220V, porque los capacitores quedan cargados de energía por bastante tiempo. Por eso hay que tener mucho cuidado si se desarma una fuente, más si estuvo funcionando recientemente.


Continuar »

Configurar servidor LDAP con STARTTLS y SSSD

Un servidor LDAP es parte central de muchos deployments, sean en la nube o en infraestructura propia.
Aplicar los principios de security in depth, es decir procurar siempre aplicar diversos niveles de seguridad contribuye a que nuestros deployments sean más seguros. Por eso en esta entrada se describe cómo integrar un servidor LDAP usando openLDAP con STARTTLS para encriptación. Se usará además GOSA como interfaz gráfica de usuario para la configuración del directorio.
Usaremos además sssd (System Security Services Daemon) que es un approach más reciente y bastante conveniente.



Esta configuración la estoy probando con containers de LXD/LXC por eso quizá los nombres de hosts algo extraños. La ventaja es que con LXC podemos probar con containers la infra que después vamos a llevar la nube (aws, Azure, etc).
La idea centrar es usar el directorio LDAP para autenticación e identificación de usuarios, por eso, aún cuando el servidor LDAP no esté expuesto directamente a Internet vamos a configurar STARTTLS para que el tráfico entre clientes LDAP y el servidor sea encriptado. También llamada oportunistic TLS nos permite utilizar el puerto LDAP estándar (389).

En la máquina que usamos como nuestra CA interna firmaremos los certificados. Lo ideal es que nuestra CA tenga una entidad intermedia o subsidiaria que será la que efectivamente firme los certificados de nuestra organización y que no requieran sites o servicios públicos. Idealmente la máquina de la CA no debiera tener conexión a internet si nos ponemos el nivel de paranoia elevado /alto :

# cd /root/ca

# openssl genrsa -out intermediate/private/ldap02-debian.lxd.key.pem 2048

# chmod 400 intermediate/private/ldap02-debian.lxd.key.pem

2) Crear el csr:

# openssl req -config intermediate/openssl.cnf -key intermediate/private/ldap02-debian.lxd.key.pem -new -sha256 -out intermediate/csr/ldap02-debian.lxd.csr.pem

3) Create certificate:

# openssl ca -config intermediate/openssl.cnf -extensions server_cert -days 999 -notext -md sha256 -in intermediate/csr/ldap02-debian.lxd.csr.pem -out intermediate/certs/ldap02-debian.lxd.cert.pem

#mkdir -p /etc/ssl/{certs,private}

(copiar los certificados de la CA (trust chain), certificado del servidor y la private key.

cp ldap02-debian.lxd.key.pem /etc/ssl/private
chown -R root:openldap /etc/ssl/private
chmod 440 /etc/ssl/private/ldap02-debian.lxd.key.pem

cp ldap02-debian.lxd.cert.pem /etc/ssl/certs
cp ca-chain.cert.pem /etc/ssl/certs

Configurar LDAP:

Configurar /etc/ldap/ldap.conf con los parametros requeridos (BASE y URI):

BASE dc=ldap02-debian,dc=lxd
URI ldap://ldap02-debian.lxd

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

# TLS certificates
TLS_CACERT /etc/ssl/certs/ca-chain.cert.pem

Creamos el siguiente archivo ldif para configurar nuestro certificado ssl:

vim /root/certs.ldif

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca-chain.cert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap02-debian.lxd.cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap02-debian.lxd.key.pem

Y lo importamos al directorio LDAP:

ldapmodify -H ldapi:/// -Y EXTERNAL -f /root/certs.ldif

(si hay algun error revisar permisos y que la ruta a los certs sea la correcta)


Probar que starttls funcione, con el parámetro -ZZ

ldapwhoami -H ldap:// -x -ZZ

Si está todo bien debemos obtener:

anonymous

Forzar usar siempre starttls (opcional pero recomendado):

Creamos el siguiente archivo ldif:

cat /root/forcetls.ldif:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

ldapmodify -H ldapi:/// -Y EXTERNAL -f /root/forcetls.ldif

Para probar podemos hacerlo con:

ldapsearch -H ldap:// -x -b "dc=ldap02-debian,dc=lxd" -LLL dn

Si la encriptación está activada obtendremos:

Confidentiality required (13)
Additional information: TLS confidentiality required


En cambio, si con la opción -ZZ forzamos el uso de starttls:

# ldapsearch -H ldap:// -x -b "dc=ldap02-debian,dc=lxd" -LLL -ZZ dn
dn: dc=ldap02-debian,dc=lxd

dn: cn=admin,dc=ldap02-debian,dc=lxd

Con esto último nos habremos asegurado que todas las solicitudes para LDAP se encripten usando STARTTLS.

Recordar: en la instalación de los clientes LDAP se deberá configurar el archivo /etc/ldap/ldap.conf de la misma manera que se indicó arriba. Asegurándose de haber deployado el certificado de la CA o chain trust y referenciarlo a la ubicación correcta.

Instalación de GOSA

Instalar los siguientes paquetes:

# apt-get install gosa gosa-plugin-sudo gosa-plugin-sudo-schema gosa-schema

La configuración básica de GOSA se hace a través de su UI. Es bastante directa. Lo importante es configurar para que use STARTTLS caso contrario no se podrá comunicar con LDAP. Para ello, luego de haber configurado GOSA por la UI debemos agregar en /etc/gosa/gosa.conf:

<location name="default"
ldapTLS="true"
config="ou=gosa,ou=configs,ou=systems,dc=ldap02-debian,dc=lxd">
<referral URI="ldap://localhost:389/dc=ldap02-debian,dc=lxd"
adminDn="cn=admin,dc=ldap02-debian,dc=lxd"
adminPassword="topsecret" />
</location>

Luego podremos ir creando nuestra base de usuarios en LDAP vía gosa:



Configurar sssd en los clientes para que autentifiquen vía LDAP

Lo que resta es configurar sssd en los clientes para que se autentifiquen vía LDAP:

Instalar paquetes para sssd:

ii sssd 1.13.4-3 System Security Services Daemon -- metapackage
ii sssd-ad 1.13.4-3 System Security Services Daemon -- Active Directory back end
ii sssd-ad-common 1.13.4-3 System Security Services Daemon -- PAC responder
ii sssd-common 1.13.4-3 System Security Services Daemon -- common files
ii sssd-ipa 1.13.4-3 System Security Services Daemon -- IPA back end
ii sssd-krb5 1.13.4-3 System Security Services Daemon -- Kerberos back end
ii sssd-krb5-common 1.13.4-3 System Security Services Daemon -- Kerberos helpers
ii sssd-ldap 1.13.4-3 System Security Services Daemon -- LDAP back end
ii sssd-proxy 1.13.4-3 System Security Services Daemon -- proxy back end
ii sssd-tools

Y la configuración de /etc/sssd/sssd.conf:

root@host01-debian:~# cat /etc/sssd/sssd.conf
[sssd]
services = nss,pam
config_file_version = 2
domains = ldap

[domain/ldap]
ldap_schema = rfc2307bis
ldap_search_base = dc=ldap02-debian,dc=lxd
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ldap02-debian.lxd:389
ldap_id_use_start_tls = True
cache_credentials = True
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/ca-chain.cert.pem


[nss]

[pam]

[sudo]

[autofs]

[ssh]

Verificar que la ubicación de los certificados de la CA sea correcta y que además el modo para el archivo config sea 0600:

# ls -l /etc/sssd/sssd.conf
-rw------- 1 root root 435 Sep 18 23:27 /etc/sssd/sssd.conf

Por último si deseamos que los directorios home de los usuarios (configurados en ldap) se creen automáticamente debemos configurar el módulo pam adecuado:

# cat /etc/pam.d/common-session
#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_sss.so
session optional pam_systemd.so
# Added for creating homedir (line to be added):
session required pam_mkhomedir.so
# end of pam-auth-update config

Continuar »