ranted on the Great Mortgage Minority Meltdown as reasons

for abandoning financial mechanisms based on trust in elites
documented my travails in configuring linux systems
This commit is contained in:
reaction.la 2024-01-12 02:10:09 +00:00
parent a92a3b60b7
commit 8f07c8dcf1
No known key found for this signature in database
GPG Key ID: 99914792148C8388
4 changed files with 120 additions and 71 deletions

View File

@ -53,6 +53,17 @@ the message type field, deserializes the message,
and despatches it to the appropriate fully typed event handler
of that state machine.
# It is remarkable how much stuff can be done without
concurrent communicating processes. Nostr is entirely
implemented over request reply, except that a whole lot
of requests and replies have an integer representing state,
where the state likely winds up being a database rowid.
The following discussion also applies if the reply-to field
or in-regards-to field is associated with a database index
rather than an instance of a class living in memory, and might
well be handled by an instance of a class containing only a database index.
# Representing concurrent communicating processes

View File

@ -534,7 +534,7 @@ lambdas and functors, but are slow because of dynamic allocation
C++ does not play well with functional programming. Most of the time you
can do what you want with lambdas and functors, using a pod class that
defines operator(\...)
defines `operator(...)`
# auto and decltype(variable)

View File

@ -144,6 +144,7 @@ Which is very effective in preventing people from moving debts off the books.
In the Great Minority Mortgage Meltdown, the SoX books were misleading to the tune
of about seven *trillion* dollars, about one hundred times as much money as the Enron scandal,
largely due to the fact that the people responsible for paying the mortgages could not be found or identified,
frequently had about as much id and evidence of actual existence as a democratic party voter,
and many of them probably did not exist, and many of the properties were not only grossly overvalued,
but pledged to multiple mortgages, or were impossible to identify,
and some of them may not have existed either. It usually said that the losses in the
@ -155,8 +156,10 @@ mansions they could not possibly afford at market prices, but market prices were
because of this artificial demand. From 2005 to 2007, it looks more like people who did not actually exist
were buying houses at prices far above market price and market prices were irrelevant.
And that the price of the property underlying the mortgage had been inflated
far above realizable value was not the only problem. The creditors frequently
And that the alleged sale price of the property underlying
the mortgage had been inflated far above realizable value,
and often far above even what the prices had been at the peak
of the bubble in 2005 was not the only problem. The creditors frequently
had strange difficulty actually finding the houses.
A person who actually exists and actually wants the house is going to sign the papers at a location

View File

@ -79,6 +79,14 @@ the OS in ways the developers did not anticipate.
## Setting up Debian in VirtualBox
### virtual box Debian install bug
Debian 12 (bookworm) install fails on a UEFI virtual disk.
The workaround is to install a base Debian 11 system as UEFI
in Virtual Box. Update /etc/apt/sources.list from Bullseye
to Bookworm. Run apt update and apt upgrade.
After that you have a functioning Debian 12 UEFI Virtual machine.
### Guest Additions
To install guest additions on Debian:
@ -133,7 +141,7 @@ autologin-user-timeout=0
nano /etc/default/grub
```
The full configuration built by `grub2-mkconfig` is built from the file `/etc/default/grub`, the file `/etc/fstab`, and the files in `/etc/grub.d/`.
The full configuration built by `update-grub` is built from the file `/etc/default/grub`, the file `/etc/fstab`, and the files in `/etc/grub.d/`.
Among the generated files, the key file is `menu.cfg`, which will contain a boot entry for any additional disk containing a linux kernel that you have attached to the system. You might then be able to boot into that other linux, and recreate its configuration files within it.
@ -154,10 +162,26 @@ Go to go to system / control center/ Hardware/ Power Management and turn off the
In the shared directory, I have a copy of /etc and ~.ssh ready to roll, so I just go into the shared directory copy them over, `chmod` .ssh and reboot.
Alternatively [manually set them](#setting-up-ssh) then
```bash
chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
```
### make the name available
You can manually edit the hosts file, or the `.ssh/config` file, which is a pain if you have a lot of machines, or fix your router to hand out
names, which cheap routers do not do and every router is different.
Or, if it is networked in virtual box bridged mode,
```bash
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install avahi-daemon
```
Which daemon will multicast the name and IP address to every machine on the network so that you can access it as «name».local
### Set the hostname
check the hostname and dns domain name with
@ -220,7 +244,7 @@ Change the lower case `h` in `PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$
I also like the bash aliases:
```text
alias ll="ls -hal"
alias ll="ls --color=auto -hal --time-style=iso"
mkcd() { mkdir -p "$1" && cd "$1"; }
```
@ -277,15 +301,11 @@ This does not necessarily correspond to order in which virtual drives have
been attached to the virtual machine
Be warned that the debian setup, when it encounters multiple partitions
that have the same UUID is apt to make seemingly random decisions as to which partitions to mount to what.
that have the same UUID (because one system was cloned from the other)
is apt to make seemingly random decisions as to which partitions to mount to what. So, you should boot from a live
cd-rom, and attach the system to be manipulated to that.
The problem is that virtual box clone does not change the partition UUIDs. To address this, attach to another linux system without mounting, change the UUIDs with `gparted`. Which will frequently refuse to change a UUID because it knows
better than you do. Will not do anything that would screw up grub.
`boot-repair` can fix a `grub` on the boot drive of a linux system different
from the one it itself booted from, but to boot a cdrom on an oracle virtual
box efi system, cannot have anything attached to SATA. Attach the disk
immediately after the boot-repair grub menu comes up.
This also protects you from accidentally manipulating the wrong system.
The resulting repaired system may nonetheless take a strangely long time
to boot, because it is trying to resume a suspended linux, which may not
@ -877,64 +897,6 @@ the ssh terminal window.
Once your you can ssh into your cloud server without a password, you now need to update it and secure it with ufw. You also need rsync, to move files around
### Remote graphical access over ssh
```bash
ssh -cX root@reaction.la
```
`c` stands for compression, and `X` for X11.
-X overrides the per host setting in `~/.ssh/config`:
```default
ForwardX11 yes
ForwardX11Trusted yes
```
Which overrides the `host *` setting in `~/.ssh/config`, which overrides the settings for all users in `/etc/ssh/ssh_config`
If ForwardX11 is set to yes, as it should be, you do not need the X. Running a gui app over ssh just works. There is a collection of useless toy
apps, `x11-apps` for test and demonstration purposes.
I never got this working in windows, because no end of mystery
configuration issues, but it works fine on Linux.
Then, as root on the remote machine, you issue a command to start up the
graphical program, which runs as an X11 client on the remote
machine, as a client of the X11 server on your local machine. This is a whole lot easier than setting up VNC.
If your machine is running inside an OracleVM, and you issue the
command `startx` as root on the remote machine to start the remote
machines desktop in the X11 server on your local OracleVM, it instead
seems to start up the desktop in the OracleVM X11 server on your
OracleVM host machine. Whatever, I am confused, but the OracleVM
X11 server on Windows just works for me, and the Windows X11 server
just does not. On Linux, just works.
Everyone uses VNC rather than SSH, but configuring login and security
on VNC is a nightmare. The only usable way to do it is to use turn off all
security on VNC, use `ufw` to shut off outside access to the VNC host's port
and access the VNC host through SSH port forwarding.
X11 results in a vast amount of unnecessary round tripping, with the result
that things get unusable when you are separated from the other compute
by a significant ping time. VNC has less of a ping problem.
X11 is a superior solution if your ping time is a few milliseconds or less.
VNC is a superior solution if your ping time is humanly perceptible, fifty
milliseconds or more. In between, it depends.
I find no solution satisfactory. Graphic software really is not designed to be used remotely. Javascript apps are. If you have a program or
functionality intended for remote use, the gui for that capability has to be
javascript/css/html. Or you design a local client or master that accesses
and displays global host or slave information.
The best solution if you must use graphic software remotely and have a
significant ping time is to use VNC over SSH. Albeit VNC always exports
an entire desktop, while X11 exports a window. Though really, the best solution is to not use graphic software remotely, except for apps.
## Install minimum standard software on the cloud server
```bash
@ -950,6 +912,79 @@ echo "Y
" |ufw enable && ufw status verbose
```
### Remote graphical access
This is done by xrdp and a windowing system. I use Mate
The server should not boot up with the windowing system running
because it mightily slows down boot, sucks up lots of memory,
and because you cannot get at the desktop created at boot through xrdp
-- it runs a different instance of the windowing system.
The server should not be created as a windowing system,
because the default install creates no end of mysterious defaults
differently on a multi user command line system to what it does
in desktop system, which is configured to provide various things
convenient and desirable in a system like a laptop,
but undesirable and inconvenient in a server.
You should create it as a server,
and install the desktop system later through the command line,
over ssh, not through the install system's gui, because the
gui install is going to do mystery stuff behind your back.
Set up the desktop after you have remote access over ssh working
At this point, you should no longer be using the keyboard and screen
you used to install linux, but a remote keyboard and screen.
```bash
apt update && apt upgrade -y
apt install mate-desktop-environment
# on ubuntu apt install ubuntu-mate-desktop
systemctl get-default
systemctl set-default multi-user.target
# on a system that was created as a server,
# set-default graphical-target
# may not work anyway
apt install xrdp -y
systemctl start xrdp
systemctl status xrdp
systemctl stop xrdp
usermod -a -G ssl-cert xrdp
systemctl start xrdp
systemctl status xrdp
systemctl enable xrdp
ufw allow 3389
ufw reload
```
```terminal_image
$ systemctl status xrdp
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2024-01-06 20:38:07 UTC; 1min 19s ago
Docs: man:xrdp(8)
man:xrdp.ini(5)
Process: 724 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/S>
Process: 733 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 735 (xrdp)
Tasks: 1 (limit: 2174)
Memory: 1.4M
CPU: 19ms
CGroup: /system.slice/xrdp.service
└─735 /usr/sbin/xrdp
systemd[1]: Starting xrdp daemon...
xrdp[733]: [INFO ] address [0.0.0.0] port [3389] mode 1
xrdp[733]: [INFO ] listening to port 3389 on 0.0.0.0
xrdp[733]: [INFO ] xrdp_listen_pp done
systemd[1]: xrdp.service: Can't open PID file /run/xrdp/xrdp.pid >
systemd[1]: Started xrdp daemon.
xrdp[735]: [INFO ] starting xrdp with pid 735
xrdp[735]: [INFO ] address [0.0.0.0] port [3389] mode 1
xrdp[735]: [INFO ] listening to port 3389 on 0.0.0.0
xrdp[735]: [INFO ] xrdp_listen_pp done
```
## Backing up a cloud server
`rsync` is the openssh utility to synchronize directories locally and