Two things that really annoy me!

Moving homes. again.

First off, I got a new VPS to house this on, size wise, I’d just plain outgrown the old one, even with SquashFS. Over on lowend box, I had spotted this one: LuxVPS

It’s not an AD, just thought the pricing seemed pretty good for 5€. One of the nice things about converting so much of my data to SquashFS is that moving single files is WAY easier to deal with!

Mice in my 1970’s teletype text editor?!

Using Mice with a 1970’s text editor

But editing text files had me facing off some feature of VIM I’d somehow not dealt with that Debian 11 set by default, and that is mouse integration!

CAN YOU BELIVE IT?

Somewhere out there, is people who use a mouse with a VI clone. 

It bares repeating

SOMEONE THINKS YOU NEED A MOUSE TO USE VI.

So much so, it’s the system default.

Good lord.

The fix is to edit /etc/vim/vimrc:


set mouse=
set ttymouse=

Problem solved. Obviously, I’m not going to remember this, but now I can right click/paste the way G’d intended it!

Stale encryption

Old rusty locks

The next source of annoyance is the ancient stunnel 4.17 that I use for altavista.superglobalmegacorp.com. I’m kind of trapped with this setup as it needs to be a 32bit ‘workstation’ OS, and I don’t want to run something as heavy as XP or Vista when NT 4.0 is more than enough. Anyways OpenSSL won’t talk to this ancient encryption, throwing this error trying to do a connection with “openssl s_client -connect 192.168.23.6:443”:

error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
Unable to establish SSL connection.

The fix, thanks to dave_thompson_085 is simple enough.

Basically, modify /etc/ssl/openssl.conf and place this at the top:


openssl_conf = default_conf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

then place this at the bottom:


[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = ssl_default_sect

[ssl_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT:@SECLEVEL=1

Now when I connect to stunnel, I can verify that I am indeed using ancient crap level security:


New, SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 19D20D30E0026E8417E00402DE939E90770D4658C3A9CFE4DB4E5F2A5454DE9D
    Session-ID-ctx:
    Master-Key: 498C648E77E9B9C944A8B1D16242240A161A05A087881C6AD300718DD9B8C443EA12FB76440B666B7C6634A7E7DBE9D5
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1718352960
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
---
DONE

I don’t care about the encryption, I could as a matter of fact just run without it, as I only need the reverse proxy aspect of it, to make the AltaVista web server accessible over the LAN/WAN/INTERNET. It’s all fronted with CloudFlare so from the end use POV it’s all encrypted anyways

A rainbow of happiness

Sunshine & rainbows!

Another nice side benefit of this SquashFS setup is that I can forever rebase the disks as the content never changes.


#!/bin/bash
# rebase the disk
rm /usr/local/vm/AltaVista/altavista-c.vmdk
rm /usr/local/vm/AltaVista/altavista-d.vmdk
rm /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_C/altavista-c.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-c.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_D/altavista-d.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-d.vmdk
qemu-img create -f vmdk -b /usr/local/vmdk/AltaVista_U/altavista-u.vmdk -F vmdk /usr/local/vm/AltaVista/altavista-u.vmdk

qemu-system-i386 -vga std -cpu pentium -m 64 \
        -vnc 192.168.23.1:6 \
        -net none  \
        -hda /usr/local/vm/AltaVista/altavista-c.vmdk \
        -hdb /usr/local/vm/AltaVista/altavista-d.vmdk \
        -hdd /usr/local/vm/AltaVista/altavista-u.vmdk \
        -device pcnet,netdev=alta,mac=5a:00:11:55:22:22  \
        -netdev tap,ifname=tap6,id=alta,script=/usr/local/vm/AltaVista/alta-up,downscript=/usr/local/vm/AltaVista/alta-down

One thing is for sure, it makes hosting AltaVista a bit easier to deal with. And for the sake of archiving, I uploaded a pre-loaded & indexed dataset Altavista Pre-Loaded (squashfs). I found that you can just copy the databases into a new VM, as long as you keep the drive letters the same as your source. So luckily, I had kept the OS on C:, installed AltaVista on D: with all the usenet posts on U:. Even better, for those strapped for space, you don’t technically need the U: drive, if you just want to search. Of course, you probably do want to look at them, but we’ve gone down this road before. And we know where it leads.

Index All the things!

Leave a Reply