Mostly because I’m an idiot, but at least I had a backup in hand.
the debs are kpe tin /var/cache/apt/archives
So a simple script like this:
ls -l *.deb | awk '{print $9}' | sed -e 's/_/\ /g' | awk '{print "apt-get install "$1}' > /tmp/missingWill go ahead and prep a simple script to re-add everything. Obviously I don’t pass it into a sudo’d bash, but heh it works.
Probably one of my quicker recoveries, since I had all the data & config’s just lost the OS.
AKA what happens when your OS is from one Debian like distribution and lags behind the rest of the world, but you want to run a parallel infastructure. Obviously for people who have sane setups their stuff is in sync and this doesn’t apply.
HOWEVER for people who use USO they will find out quickly that it’s a Debian derived MIPS64EL based distribution, but they don’t keep any MIPSEL (32bit) binaries. So I was thinking add in the dpkg arch, and some deb sources and I’d be good to go, right? Except the stuff is out of step so what happens is that UOS decides it wants to replace the OS with what is on the mipsel repos. Even when specfiying the arch’s directly.
deb [by-hash=force arch=mips64el] https://professional-packages.chinauos.com/desktop-professional eagle main contrib non-free
deb [arch=mipsel] http://deb.debian.org/debian buster main contrib non-freeI tried.
So the good news is that I asked around and found a solution that I’d never heard of, “debootstrap”. The general page is here:
What it boils down to is that it’s a script set that will download enough DEB’s and extract them onto a directory and prep it out as a chroot/jail. And you can specify whatever architecture you want, you can even use qemu to run totally alien stuff! I’d never heard of this before, such a shame.
From my rough notes I did something like this:
/usr/sbin/debootstrap --arch mipsel buster /usr/local/mipsel http://deb.debian.org/debianThis will install the mipsel platform of Buster into /usr/local/mipsel
running the following gets me into the chroot/jail/container..
LANG=C.UTF-8 sudo chroot /usr/local/mipsel /bin/bashYES it’s that simple! Although there is some house cleaning to be done:
apt install makedev
mount none /proc -t proc
cd /dev
MAKEDEV genericMaking the devices sure took long enough, but now I could do the regular update, add in some compilers and stuff, X11, and whatnot and get things going. Remember to mess around with xauth to get X11 forwarding from chroot working
Now for the ‘fun’ part of linking the libs…
ln -fs /usr/local/mipsel/usr/lib/mipsel-linux-gnu /usr/lib32
ln -fs /usr/lib32/ld.so.1 /lib/ld.so.1Then you need to ‘config’ ld.config with
cat > /etc/ld.so.conf.d/mipsel-buildroot.conf
/usr/local/mipsel/usr/lib/mipsel-linux-gnu
^DPhew we are almost there!
$ file /usr/local/mipsel/bin/dash
/usr/local/mipsel/bin/dash: ELF 32-bit LSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=22877e3a9a83675b22a121c9d2f8943d7339e7db, stripped
$ sudo ldconfig;/usr/local/mipsel/bin/dash
$And just like that we now can run dynamically linked 32bit MIPSEL binaries on UOS.
As a bonus (from stackexcahnge) here is how to run Xauth to get forwarding from the chroot. From the ‘base’ physical machine run:
$ xauth list
latitude/unix:0 MIT-MAGIC-COOKIE-1 d4474d13cNow with that cookie run this in the chroot:
# xauth add latitude/unix:0 MIT-MAGIC-COOKIE-1 d4474d13c
# xclockand the 32bit Xclock should pop up on your 64bit desktop.
Wasn’t that fun?!
Well after my last Star Wars Galaxies adventure, where I tried to run MySQL on Linux Subsystem for Windows v1, I got some weird shared memory error, and it wouldn’t run. Even the old BSDDB engine was bombing out trying to create files. So fine, whatever I thought I could move on, and that is when I found out that somehow OpenSSL & Python had utterly collided.
Python 1.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/ssl.py", line 98, in
import _ssl # if we can't import it, let the error propagate
ImportError: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_0' not found (required by /usr/lib/python2.7/lib-dynload/_ssl.x86_64-linux-gnu.so)
>>>
Well isn’t that great. I tried un-installing & re-installing Python over and over, along with trying to force re-install OpenSSL. No dice.
So what finally got it working for me was to purge OpenSSL.
apt-get purge libssl1.1
And after that it pulled out everything that was using it, well over 500MB of stuff I’d installed. And for good measure I followed up with the autoremove for an additional 384MB of stuff to remove. And then for the final step, of just installing Python:
root@HUANANZHIX79:~# apt-get install python2.7
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libpython2.7-stdlib libssl1.1
Suggested packages:
python2.7-doc
The following NEW packages will be installed:
libpython2.7-stdlib libssl1.1 python2.7
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,537 kB of archives.
After this operation, 12.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian stretch/main amd64 libssl1.1 amd64 1.1.0j-1~deb9u1 [1,354 kB]
Get:2 http://deb.debian.org/debian stretch/main amd64 libpython2.7-stdlib amd64 2.7.13-2+deb9u3 [1,897 kB]
Get:3 http://deb.debian.org/debian stretch/main amd64 python2.7 amd64 2.7.13-2+deb9u3 [285 kB]
Fetched 3,537 kB in 0s (13.2 MB/s)
Preconfiguring packages ...
Selecting previously unselected package libssl1.1:amd64.
(Reading database ... 27441 files and directories currently installed.)
Preparing to unpack .../libssl1.1_1.1.0j-1~deb9u1_amd64.deb ...
Unpacking libssl1.1:amd64 (1.1.0j-1~deb9u1) ...
Selecting previously unselected package libpython2.7-stdlib:amd64.
Preparing to unpack .../libpython2.7-stdlib_2.7.13-2+deb9u3_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ...
Selecting previously unselected package python2.7.
Preparing to unpack .../python2.7_2.7.13-2+deb9u3_amd64.deb ...
Unpacking python2.7 (2.7.13-2+deb9u3) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Setting up libssl1.1:amd64 (1.1.0j-1~deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ...
Setting up python2.7 (2.7.13-2+deb9u3) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
So now you think its going to be broken right? It’s the same libssl package! I didn’t even run an ‘apt-get update’. And guess what?! You would be wrong.
root@HUANANZHIX79:~# python
Python 2.7.13 (default, Sep 26 2018, 18:42:22)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>>
That’s right, it’s now working.
Speaking of Picard, I hear there will be a new series, inspiringly named ‘Picard’. Apparently it’s going down the same path as STD, complete with a lack of backers, and merch. I’m hoping it’ll be something watchable, although they certainly cannot afford any of the TNG cast as they apparently have zero budget. Maybe it’ll end up as another ‘Jake Skywalker’ or ‘Not my Picard’. But the bad reboot 25% contractual difference could be the difference between something new, or something so divergent that there was no point in even attempting to be a Trek.
Thanks to a quick search here is how to re-create it:
cat </etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. exit 0 EOF chmod +x /etc/rc.local systemctl daemon-reload systemctl start rc-local systemctl status rc-local
Nice.
Yay
I still run an ancient BBS, using Synchronet on OS/2. The problem being that I not only get port scanned an incredible amount of times, but so many things out there now logon as root/root and they think they are on a Linux machine and can then shell script their way into some exploits. Ive tried rate limiting, and other methods, but I end up with so many distributed connections that SIO can’t cope and it’ll crash. A reboot will fix it, of course, but rebooting 2-3 times a day is a bummer. So I thought I’d front my BBS with a stub BBS, which means building Synchronet from source. And while there is some guides on how to do this, I naturally hit some weird undocumented error.
So yeah, get ready for this fun error:
jsapi.cpp: In function ‘JSIdArray* JS_Enumerate(JSContext*, JSObject*)’:
jsapi.cpp:3988:16: error: cannot convert ‘bool’ to ‘JSIdArray*’ in return
return false;
So it turns out that GCC 6 and higher won’t compile the older javascript engine that Synchronet relies on. Ok, so I figured I would just fix the cast and go on my way. But no, as part of the build process once it figures out that I’ve tampered with a file it’ll re-unpack the engine and break on the same error again. And this is why I find things that try to be so ‘easy’ and holding (I’m looking at you Cmake!!!!) end up being totally black box, and absolutely useless.
So what I really need is g++ 4.x, and what is the quickest and easiest way to get the old compiler? Ugh, grab the package from the prior version Jessie. Seriously. Add this into your /etc/apt/sources.list
deb http://ftp.us.debian.org/debian/ jessie main contrib non-free
and then run:
apt-get update && apt-get install g++-4.9
And take the new line out of /etc/apt/sources.list or you will have hell to pay.
After that it was a matter of modifying some of the logon code to streamline the logon process, and to gut the ‘ham radio’ door into something that’ll telnet to the OS/2 BBS. After a bit of work it actually works. I even tested Zmodem, and that works too!
Logging into the proxy
I need some ASCII art or something. That and probably turn off new user registration. Guest access is all anyone can get on the proxy.
Telnet menu
I could probably do more here. Years ago I ran some public access Ancient UNIX stuff, but the problems were that it got slammed from the internet. But if Synchronet can keep up with the idiots on the outside, I guess this works as a jump point into something else? I may have to see about adding some 386BSD, and Linux 1.0
QEMUOS2 via modern Synchronet
And here we are, at the old BBS. I never got that many people to begin with, and I did like having the only OS/2 BBS on the internet up. The other BBS O-Zone seems to have given up, as their domain expired. So it’s just me, once more again.
I’m sure the vast majority of people won’t care, but I guess I finally hit the tipping point where 1996’s SIO just can’t keep up in 2017’s world of relentless port knocking.
More so my own use, but this article on linuxconfig.org was a LOT of help.
Basically and with no explanation the steps are :
apt-get update
apt-get upgrade
apt-get dist-upgrade
dpkg -C
apt-mark showhold
cp /etc/apt/sources.list /etc/apt/sources.jessie
sed -i ‘s/jessie/stretch/g’ /etc/apt/sources.list
apt-get update
apt list –upgradable
apt-get upgrade
apt-get dist-upgrade
aptitude search ‘~o’
And that’s it!
I also took the BBR congestion update tip from tipsforchina.com
wget –no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh
And adding the following to /etc/sysctl.conf after the “net.ipv4.tcp_congestion_control = bbr” line.
fs.file-max = 51200
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 250000
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_mem = 25600 51200 102400
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
For some reason I had issues for this to automatically pick up building Qemu 2.8.0 on Ubuntu 16.10 (Which is really Debian)…
Anyways, be sure to have the needed dev components installed. Â If you have a FRESH system, natrually you’ll need a lot more.
apt-get install libvdeplug-dev
apt-get install libvde-dev
apt-get install ncurses-dev
editing the file config-host.mak, I found I needed to add the following to turn on ncurses & VDE:
CONFIG_CURSES=y
CONFIG_VDE=y
And lastly add in the following libs to the libs_softmmu, to ensure it’ll link
-lncurses -lvdeplug
And now I’m good!
From my notes on flags needed to run Qemu the old fashioned way:
-net none -device pcnet,mac=00:0a:21:df:df:01,netdev=qemu-lan -netdev vde,id=qemu-lan,sock=/tmp/local/
This will join it to the VDEÂ listening in /tmp/local
Obviously I have something more interesting and more evil going on….
Ugh. nothing like ancient crypto, major security vulnerabilities, and ancient crap. Â So first I’m going to use Juniper’s SDK (get it while you can, if you care). Â Note that the product is long since EOL’d, and all support is GONE. Â I’m using Debian 7 to perform this query, although I probably should be using something like 4 or 5. Â Anyways first off is that the python examples require “Ft.Xml.Domlette” which doesn’t seem to have a 4Suite-XML package. Â SO let’s build it the old fashioned way:
 apt-get install build-essential python-dev
wget http://pypi.python.org/packages/source/4/4Suite-XML/4Suite-XML-1.0.2.tar.bz2
tar -xvvf 4Suite-XML-1.0.2.tar.bz2
cd 4Suite-XML-1.0.2
./setup.py install
Well (for now) and in my case I could reconfigure tomcat to be slightly more secure. Otherwise running the examples gives this fun filled error:
ssl.SSLError: [Errno 1] _ssl.c:504: error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
Naturally as time goes on this will not work anymore, and I’ll need a stale machine to query this stale service. Using ssl shopper’s Tomcat guide, I made changes to the server.xml file on the vGW SD VM. (Don’t forget to enable SSH in the settings WebUI, and then login as admin/<whatever password you gave> then do a ‘sudo bash’ to run as root, screw being nice!
# diff -ruN server.xml-old server.xml
--- server.xml-old 2017-01-14 18:20:07.000000000 +0800
+++ server.xml 2017-01-14 19:31:36.000000000 +0800
@@ -98,7 +98,7 @@
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"
- ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
+ ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, ECDH-RSA-AES128-SHA"
keystoreFile="/var/lib/altor/cert/public_keystore" keystorePass="altoraltor"/>
Naturally don’t forget to restart Tomcat, which does take forever:
bash-3.2# /etc/init.d/tomcat restart
Stopping tomcat: [ OK ]
Starting tomcat: [ OK ]
And now I’m FINALLY able to run  one of the sample scripts
# ./policyToXML.py –grp 1
<?xml version=”1.0″ encoding=”UTF-8″?>
<policy xmlns=”urn:altor:center:policy”>
<revision>340</revision>
<name>Global Policy</name>
<id>1</id>
<rev>1</rev>
<type>G</type>
<groupId>-1</groupId>
<machineId>-1</machineId>
<Inbound>
And you get the idea. Â Certainly on the one hand it’s nice to get some data out of the vGW without using screen captures or anything else equally useless, and it sure beats trying to read stuff like this:
vGW VM effective policy for a VM
What on earth was Altor/Juniper thinking?  Who thought making the screen damned near impossible to read was a “good thing”â„¢
I just wish I’d known about the SDK download on the now defunct firefly page a few years ago as it’d have saved me a LOT of pain, but as they say, not time like the present.
Naturally someone here is going to say, upgrade to the last version it’ll fix these errors, and sure it may, but are you going to bet a production environment that is already running obsolete software on changing versions? Â Or migrate to a new platform? Sure, the first step I’d want of course is a machine formatted rule export of the existing rules. Â And here we are.