You will need to do another `m-a prepare` and to reinstall it after a
`apt-get -qy dist-upgrade`. Sometimes you need to do this after a mere
upgrade to Debian or to Guest Additions. Every now and then, guest
additions gets mysteriously broken on Debian, due to automatic operating
system updates in the background, the system will not shut
down correctly, and guest additions has to be reinstalled with a
`shutdown -r`. Or copy and paste mysteriously stops working.
On Debian lightdm mate go to system/ control center/ Look and Feel/ Screensaver and turn off the screensaver screen lock
Go to go to system / control center/ Hardware/ Power Management and turn off the computer and screen sleep.
To set automatic login on lightdm-mate
```bash
nano /etc/lightdm/lightdm.conf
```
In the `[Seat:*]` section of the configuration file (there is another section of this configuration file where these changes have no apparent effect) edit
```ini
#autologin-guest=false
#autologin-user=user
#autologin-user-timeout=0
```
to
```ini
autologin-guest=false
autologin-user=cherry
autologin-user-timeout=0
```
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.
On the source machine
```bash
scp -r .ssh «destination»:~
scp -r etc «destination»:/
```
On the destination machine
```bash
chmod 700 .ssh && chmod 600 .ssh/*
```
I cannot do it all from within the destination machine, because linux cannot follow windows symbolic links.
### Set the hostname
check the hostname and dns domain name with
```bash
hostname && domainname -s && hostnamectl status
```
And if need be, set them with
```bash
domainname -b reaction.la
hostnamectl set-hostname reaction.la
```
Your /etc/hosts file should contain
```text
127.0.0.1 localhost
127.0.0.1 reaction.la
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
```
To change the host ssh key, so that different hosts have different
hostnames after I copied everything to a new instance:
```bash
cd /etc/ssh
cat sshd* |grep HostKey
#Make sure that `/etc/ssh/sshd_config` has the line
If the host has a domain name, the default in `/etc/bash.bashrc` will not display it in full at the prompt, which can lead to you being confused about which host on the internet you are commanding.
When an account is disabled in this manner, you cannot login at the
terminal, and may be unable to ssh in, but you can still get into it by `su -l cherry` from the root account. And if you have disabled the root account,
but have enabled passwordless sudo for one special user, you can still get
into the root account with `sudo -s` or `sudo su -l root` But if you disable
the root account in this manner without creating an account that can sudo
into root passwordless, you are hosed big time. So instead, once `ssh` is
working, give one user passwordless sudo, make sure you can ssh into that
account, and disable password and ssh access to the root account.
You can always undo the deliberate corruption by setting a new password,
When the OS detects the cpu idling while waiting for pages to be loaded
into memory, should disable one process so its pages do not get loaded for
a while, and derank all pages in memory that belong to that process, and
derank all pages that belong to processes waiting on that process. When the
cpu has idle time, and nothing to do for enabled processes, because
everything they need has been done, and is only awaiting for disabled
processes to get their pages loaded, then the OS can re-enable a disabled
process, whereupon its virtualed paged get loaded back into physical
memory, possibly resulting in some other process starting to thrash and
getting disabled. So instead paging out the least recently used page, pages out an entire process, and stalls it until the cpu is adequately responsive to the remaining processes, and has been adequately responsive for a little
while. This is inefficient, but it is a lot more efficient than a computer
thrashing on paging. If the computer is stalling waiting on page load, then
it is just running more processes than it can run, and the least recently used page algorithm is not going to accomplish anything useful. Some entire
processes just have to be paged out, and stay paged out, until the
remaining processes have completed and are idling. A thrashing computer
is not running anything at all. Better that is run some things, and from time
to time changes those things.
When the cpu has nothing to do because all the processes are waiting for pages to be loaded, something has to be done.
To have it look like a cloud server, but one you can easily snapshot and
restore, set it up in bridged mode. Note the Mac address. After having
it is running as a normal system, and you can browse the web with it,
after guest additions and all that, then shut it down, go to your
router, and give it a new static IP and a new entry in hosts.
Then configure ssh access to root. so that you can go `ssh <server>`as
if on your real cloud system. See setting up a [server in the cloud](#setting-up-a-headless-server-in-the-cloud)
On a system that only I have physical access to and which runs no services
that can be accessed from outside my local network my username is
always the same and the password always a short easily guessed single
word. Obviously if your system is accessible to the outside world, you
need a strong password. An easy password could be potentially really bad
if we have openssh-server installed, and ssh can be accessed from outside.
If building a headless machine with openssh-server (the typical cloud or
remote system) then need to set up public key sign in only, if the machine
should contain anything valuable. Passwords are just not good enough –
you want your private ssh key on a machine that only you have physical
access to, and runs no services that anyone on the internet has access to,
and which you don’t use for anything that might get it infected with
malware, and you use that private key to access more exposed machines
by ssh public key corresponding to that private key.
```bash
apt-get -qy update && apt-get -qy upgrade
# Fetches the list of available updates and
# strictly upgrades the current packages
```
To automatically start virtual boxes on bootup, which we will need to do
if publishing them, Open VirtualBox and right click on the VM you want
to autostart, click the option to create a shortcut on the desktop, cut
the shortcut. Open the windows 10“Run” box (Win+R) and enter
shell:startup Paste the shortcut. But all this is far too much work if
we are not publishing them.
If a virtual machine is always running, make sure that the close default
is to save state, for otherwise shutdown might take too long, and
windows might kill it when updating.
If we have a gui, don’t do openssh. Terminal comes up with Ctrl Alt T
# Directory Structure
## Linux
`/usr`
: Secondary hierarchy for read-only user data; contains the majority
of (multi-)user utilities and applications.
> `/usr/bin`
> : Non-essential command binaries (not needed in single user mode);
> for all users.
>
> `/usr/include`
> : Standard include files grouped in subdirectories, for example
> `/usr/include/boost`
>
> `/usr/lib`
> : Libraries for the binaries in /usr/bin and /usr/sbin.
>
> > `/usr/lib<qual>`
> > : Alternate format libraries, e.g. /usr/lib32 for 32-bit libraries
> > on a 64-bit machine (option)
>
> `/usr/local`
> : Tertiary hierarchy for local data, specific to this host.
> Typically has further subdirectories, e.g., bin, lib, share.
>
> `/usr/sbin`
> : Non-essential system binaries, e.g., daemons for various
> network-services. Blockchain daemon goes here.
>
> `/usr/share`
> : Architecture-independent (shared) data. Blockchain goes in a
> subdirectory here.
>
> `/usr/src`
> : Source code. Generally release versions of source code. Source
> code that the particular user is actively working on goes in the
> particular user’s `~/src/` directory, not this directory.
>
> `~/.<program>`
> : Data maintained by and for specific programs for the particular
> user, for example in unix `~/.Bitcoin` is the equivalent of
> `%APPDATA%\Bitcoin` in Windows.
>
> `~/.config/<program>`
> : Config data maintained by and for specific programs for the
> particular user, so that the users home directory does not get
> cluttered with a hundred `.<program>` directories.
>
> `~/.local/<program>`
> : Files maintained by and for specific programs for the particular
> user.
>
> `~/src/`
> : Source code that you, the particular user, are actively working
> on, the equivalent of `%HOMEPATH%\src\` in Windows.
>
> > `~/src/include`
> > : header files, so that they can be referenced in your source code
> > by the expected header path, thus for example this directory will
> > contain, by copying or hard linking, the `boost` directory so that
> > standard boost includes work.
# Setting up a headless server in the cloud
## Setting up ssh
Login by password is second class, and there are a bunch of esoteric
special cases where it does not quite 100% work in all situations,
because stuff wants to auto log you in without asking for input.
Putty is the windows ssh client, but you can use the Linux ssh client in
windows in the git bash shell, and the Linux remote file copy utility
`scp` is way better than the putty utility PSFTP.
Usually a command line interface is a pain and error prone, with a
multitude of mysterious and inexplicable options and parameters, and one
typo or out of order command causing your system to unrecoverably die,but even though Putty has a windowed interface, the command line
interface of bash is easier to use.
It is easier in practice to use the bash (or, on Windows, git-bash) to manage keys than PuTTYgen. You generate a key pair with
```bash
ssh-keygen -t ed25519 -f keyfile
```
(I don't trust the other key algorithms, because I suspect the NSA has been up to cleverness with the details of the implementation.)
On windows, your secret key should be in `%HOMEPATH%/.ssh`, on linux
in `/home/cherry/.ssh`, as is your config file for your ssh client, listing
the keys for hosts. The public keys of your authorized keys are in
`/home/cherry/.ssh/authorized_keys`, enabling you to login from afar as
that user over the internet. The linux system for remote login is a cleaner
and simpler system that the multitude of mysterious, complicated, and
failure prone facilities for remote windows login, which is a major reason
why everyone is using linux hosts in the cloud.
In Debian, I create the directory `~/.ssh` for the user, and, using the
editor nano, the file `authorized_keys`
```bash
mkdir ~/.ssh
nano ~/.ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/*
```
I set the ssh session host IP under /Session, the auto login username
under /Connection/data, the autologin private key under
/Connection/ssh/Auth.
If I need KeepAlive I set that under /Connection
I make sure auto login works, which enables me to make `ssh` do all sorts of
things, then I disable ssh password login, restrict the root login to only be
permitted via ssh keys.
In order to do this, open up the SSHD config file (which is ssh daemon
config, not ssh_config. If you edit this into the the ssh_config file
everything goes to hell in a handbasket. ssh_config is the global
.ssh/config file):
```bash
nano /etc/ssh/sshd_config
```
Your config file should have in it
```default
HostKey /etc/ssh/ssh_host_ed25519_key
X11Forwarding yes
AllowAgentForwarding yes
AllowTcpForwarding yes
TCPKeepAlive yes
AllowStreamLocalForwarding yes
GatewayPorts yes
PermitTunnel yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin prohibit-password
ciphers chacha20-poly1305@openssh.com
macs hmac-sha2-256-etm@openssh.com
kexalgorithms curve25519-sha256
pubkeyacceptedkeytypes ssh-ed25519
hostkeyalgorithms ssh-ed25519
hostbasedacceptedkeytypes ssh-ed25519
casignaturealgorithms ssh-ed25519
```
`PermitRootLogin` defaults to prohibit-password, but best to set it
explicitly Within that file, find the line that includes
`PermitRootLogin` and if enabled modify it to ensure that users can only
connect with their ssh key.
`ssh` out of the box by default allows every cryptographic algorithm under the sun, but we know the NSA has been industriously backdooring cryptographic code, sometimes at the level of the algorithm itself, as with their infamous elliptic curves, but more commonly at the level of implementation and api, ensuring that secure algorithms are used in a way that is insecure against someone who has the backdoor, insecurely implementing secure algorithms. On the basis of circumstantial evidence
and social connections, I believe that much of the cryptographic code used
by ssh has been backdoored by the nsa, and that this is a widely shared
secret.
They structure the api so as to make it overwhelmingly likely that the code
will be used insecurely, and subtly tricky to use securely, and then make
sure that it is used insecurely. It is usually not that the core algorithms are
backdoored, as that the backdoor is on a more human level, gently steering
the people using core algorithms into a hidden trap.
The backdoors are generally in the interfaces between layers, the apis,
which are subtly mismatched, and if you point at the backdoor they say
"that is not a backdoor, the code is fine, that issue is out of scope. File a
bug report against someone else's code. Out of scope, out of scope."
And if you were to file a bug report against someone else's code, they
would tell you they are using this very secure NSA approved algorithm
with the approved and very secure api, the details of the cryptography are
someone else's problem, "out of scope, out of scope", and they have
absolutely no idea what you are talking about, because what you are
talking about is indeed very obscure, subtle, complicated, and difficult to
understand. The backdoors are usually where one api maintained by one
group is using a subtly flawed api maintained by another group.
The more algorithms permitted, the more places for backdoors. The
certificate algorithms are particularly egregious. Why should we ever
allow more than one algorithm, the one we most trust?
Therefore, I restrict the allowed algorithms to those that I actually use, and
only use the ones I have reason to believe are good and securely
implemented. Hence the lines:
```default
HostKey /etc/ssh/ssh_host_ed25519_key
ciphers chacha20-poly1305@openssh.com
macs hmac-sha2-256-etm@openssh.com
kexalgorithms curve25519-sha256
pubkeyacceptedkeytypes ssh-ed25519
hostkeyalgorithms ssh-ed25519
hostbasedacceptedkeytypes ssh-ed25519
casignaturealgorithms ssh-ed25519
```
Not all ssh servers recognize all these configuration options, and if you
give an unrecognized configuration option, the server dies, and then you
cannot ssh in to fix it. But they all recognize the first three, `HostKey,
ciphers, macs` which are the three that matter the most.
To put these changes into effect:
```bash
shutdown -r now
```
Now that putty can do a non interactive login, you can use `plink` to have a
script in a client window execute a program on the server, and echo the
output to the client, and psftp to transfer files, though `scp` in the Git Bash
window is better, and `rsync` (Unix to Unix only, requires `rsync` running on
On windows, FileZilla uses putty private keys to do scp. This is a much
more user friendly and safer interface than using scp – it is harder to
issue a catastrophic command, but rsync is more broadly capable.
Life is simpler if you run FileZilla under linux, whereupon it uses the same
keys and config as everyone else.
All in all, on windows, it is handier to interact with Linux machines
using the Git Bash command window, than using putty, once you have set
up `~/.ssh/config` on windows.
Of course windows machines are insecure, and it is safer to have your
keys and your `~/.ssh/config` on Linux.
Putty on Windows is not bad when you figure out how to use it, but ssh
in Git Bash shell is better:\
You paste stuff into the terminal window with right click, drag stuff
out of the terminal window with the mouse, you use nano to edit stuff in
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
OK, MariaDB is working. We will use this trivial database and easily
guessed `example_user` with the easily guessed password
`mypassword` for more testing later. Delete him and his database
when your site has your actual content on it.
### domain names and PHP under nginx
Check again that the default nginx web page comes up when you browse to the server.
Create the directories `/var/www/blog.reaction.la` and `/var/www/reaction.la` and put some html files in them, substituting your actual domains for the example domains.
The first server is the default if no domain is recognized, and redirects the
request to an actual server, the next two servers are the actual domains
served, and the last server redirects to the second domain name if the
domain name looks a bit like the second domain name. Notice that this
eliminates those pesky `www`s.
The root tells it where to find the actual files.
The first location tells nginx that if a file name is not found, give a 404 rather than doing the disastrously clever stuff that it is apt to do, and the second location tells it that if a file name ends in `.php`, pass it to `php7.3-fpm.sock` (you did substitute your actual php fpm service for `php7.3-fpm.sock`, right?)
Now check that your configuration is OK with `nginx -t`, and restart nginx to read your configuration.
```bash
nginx -t
systemctl restart nginx
```
Browse to those domains, and check that the web pages come up, and that
www gets redirected.
Now we will create some php files in those directories to check that php works.
certbot run -a manual --preferred-challenges dns -i nginx -d reaction.la -d blog.reaction.la
nginx -t
```
This does not set up automatic renewal. To get automatic renewal going,
you will need to renew with the `webroot` challenge rather than the `manual`
once DNS points to this server.
But if you are doing this, not on your test server, but on your live server, the easy way, which will also setup automatic renewal and configure your webserver to be https only, is:
Adjust `$table_prefix = 'wp_';` in `wp_config.php` if necessary.
```bash
systemctl start php7.3-fpm.service
systemctl start nginx
```
Your blog should now work.
## Logging and awstats.
### Logging
First create, in the standard and expected location, a place for nginx to log stuff.
```bash
mkdir /var/log/nginx
chown -R www-data:www-data /var/log/nginx
```
Then edit the virtual servers to be logged, which are in the directory `/etc/nginx/sites-enabled` and in this example in the file `/etc/nginx/sites-enabled/config`
```text
server {
server_name reaction.la;
root /var/www/reaction.la;
…
access_log /var/log/nginx/reaction.la.access.log;
error_log /var/log/nginx/reaction.la.error.log;
…
}
```
The default log file format logs the ips, which in a server located in the cloud might be a problem. People who do not have your best interests at heart might get them.
So you might want a custom format that does not log the remote address. On the other hand, Awstats is not going to be happy with that format. A compromise is to create a cron job that cuts the logs daily, a cron job that runs Awstats, and a cron job that then deletes the cut log when Awstats is done with it.
There is no point to leaving a gigantic pile of data, that could hang you and your friends, sitting around wasting space.
## Postfix and Dovecot
[Postfix and Dovecot are a pile of matchsticks and glue] from which you are
expected to assemble a boat.
Probably I should be using one of those email setup packages that set up
everything for you. [Mailinabox] seems to be primarily tested and
developed on ubuntu, and is explicitly not supported on debian.
[Mailcow] however, is Debian. But [Mailcow] wants 6GiB of ram, plus one
GiB swap, plus twenty GiB disk. Ouch. [Mailinabox] can get by with one
GiB of ram, plus one GiB of swap. Says 512MiB is OK, though two GiB
of ram is strongly recommended.
[Mailinabox] wants the domain name `box.yourdomain.com`, and, after it is
set up, wants the nameservers `ns1.box.yourdomain.com` and
`ns2.box.yourdomain.com`. They, fortunately, have a namecheap tutorial.
name will be sent from one and only one network address.
A DKIM record publishes a digital signature for sent mail, to prevent mail
from being modified or fake mails being injected as it goes through the
multiple intermediate servers.
By the time the ultimate recipient sees the email, no end of intermediate
computers have had their hands on it, but pgp signing is obviously
superior, since that is controlled by the actual sender, not one more
intermediary. DKIM is the not quite good enough being the enemy of the
good enough.
Worse, DKIM means that any email sent from your server is signed by
your server, so if you send a private message, and someone defects on you
by making it public, hard to claim that he is making it up. Sometimes you
want your emails signed with a signature verifiable by third parties, and
sometimes this is potentially dangerous. Gpg allows you to sign some
things and not other things. DKIM means that everything gets signed,
without you being aware of it.
DKIM renders all messages non repudiable, and some messages vitally
need to be repudiable.
Gpg is better than DKIM, but has the enormous disadvantage that it
cannot authenticate except by signing. If you send a message to a single
recipient or a quite small number of recipients, you usually want him to
know for sure it is from you, and has not been altered in transit, but not be
able to prove to the whole world that it is from you.
A DMARK record can tell the recipient that mail from
`rhocoin.org` will always and only come senders like
`user@rhocoin.org`. This can be an inconvenient restriction on
one's ability to use a more relevant identity.
Further, intermediate servers keep manging messages sent through them,
breaking the DKIM signatures, resulting in no end of spurious error messages
You want to stop other people's email servers from misbehaving on the
sender addresses. You don't want to stop your server from misbehaving.
Trouble with SPF and DKIM is that, without DMARK, they have no
impact on the sender address, thus don't stop spearphishing attacks using
your identity. They do stop spam attacks from getting your server
blacklisted by using your server identity to send junk mail.
SPF is sufficient to stop your server from getting blacklisted, and largely
irrelevant to preventing spearphishing. But SPF with DMARK at least
does something about spearphishing, while DKIM with DMARK does a far more
thorough job on spearphishing, but produces a lot of false warnings due to
intermediate servers mangling the email in ways that invalidate the signature.
The only useful thing that DMARK can do is ensure *address alignment*
with SPF and DKIM, so that only people who can perform an email login
to your server can send email as someone who has such a login.
But DKIM is complicated to install, and a lot more complicated to manage
because you will be endlessly struggling to resolve the problem of
signatures being falsely invalidated. It may be far more effective against
spearphishing if the end user pays attention, but if people keep seeing
false warnings, they are being trained to ignore valid warnings.
A solution to all these problems is to [use the value `ed25519-sha256` for `a=` in the DKIM header](https://www.mailhardener.com/kb/how-to-use-dkim-with-ed25519)
(which ensures that obsolete intermediaries will
ignore your DKIM, thus third parties will see fewer false warnings) and to
have a [cron job that regularly rotates your DKIM keys](https://rya.nc/dkim-privates.html "DKIM: Show Your Privates"), *and publishes the
old secret key on the DNS 36 hours after it has been rotated out* under the
`n=OldSecret_...` field of the DKIM record, thus rendering your emails
deniable. (RSA keys are inconveniently large for this protocol, since they
do not fit in a DNS record)
But that is quite bit of work, so I just have not gotten around to it. No one
seems to have gotten around to it. Needs to be part of [Mailinabox] so that it
becomes a standard.
Until you can install DKIM with a cron job that renders email repudiable, do
not install DKIM. (And disable it if [Mailinabox] enables it.])
### Install Postfix
Here we will install postfix on debian so that it can be used to send emails
by local users and applications only - that is, those installed on the same
server as Postfix, such as your blog, mailutils, and Gitea, and can receive
After that, you’ll get another window to set the domain name of the site that is sending the email:
{width=100%}
The `System mail name` should be the same as the name you assigned to the server when you were creating it. When you’ve finished, press `TAB`, then `ENTER`.
You now have Postfix installed and are ready to modify its configuration settings.
### configuring postfix
```bash
postconf -e home_mailbox=Maildir/
```
Which is incompatible with lots of modern mail software, but a lot more
compatible with all manner of programs trying to use Postfix, including
Dovecot
Your forwarding file is, by default, broken. It forwards all administrative
system generated email to the nonroot local user `deb10` who probably does
not exist on your system.
Set up forwarding, so you’ll get emails sent to `root` on the system at your
personal, external email address or to a suitable nonroot local user, or
create the local user `deb10`.
To configure Postfix so that system-generated emails will be sent to your
email address or to some other non root local user, you need to edit the
`/etc/aliases` file.
```bash
nano /etc/aliases
```
```default
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: «your_email_address»
```
After changing `/etc/aliases` you must issue the command `newaliases` to inform the mail system. (Rebooting does not do it.)
`/etc/aliases` remaps mail to users on your internal mail server, but likely your mail server is also the MX host for another domain. For this, you are going to need a rather more powerful tool, which I address later.
The `postmaster: root` setting ensures that system-generated emails are sent
to the `root` user. You want to edit these settings so these emails are rerouted
to your email address. To accomplish that, replace «your_email_address»
with your actual email address, or the name of a non root user.. Most systems do not allow email clients to
login as root, so you cannot easily access emails that wind up as `root@mail.rhocoin.org`
Probably you should create a user `postmaster`
If you’re hosting multiple domains on a single server, the other domains
must passed to Postfix using the `mydestination` directive if other people ware going tosend email addressed to users on those domains. But
chances are you also have other domains on another server, which declare in
their DNS this server as their MX record. `mydestination` is not the place
for the domain names of those servers, and putting them in `mydestination`
is apt to result in mysterious failures.
Those other domains, not hosted on this physical machine, but whose MX
record points to this machine are [virtual_alias_domains](#virtual-domains-and-virtual-users) and postfix has to
handle messages addressed to such users differently
Set the mailbox limit to an appropriate fraction of your total available disk space, and the attachment limit to an appropriate fraction of your mailbox size limit.
Check that `myhostname` is consistent with reverse ip search. (It should already be if you setup reverse IP in advance)
Set `mydestination` to all dns names that map to your server (it probably already does)
If you see a pile of warnings `warning symlink leaves directory: /etc/postfix/./makedefs.out` that is just noise. Turn it off by replacing the symbolic link with a hard link
# You don't want an error message response for invalid email
# addresses, as this may reveal too much to your enemies.
```
Every time your `/etc/postfix/virtual` is changed, you have to recompile it
into a hash database that postfix can actually use, with the command:
```bash
postmap /etc/postfix/virtual && postfix reload
```
#### set up an email client for a virtual domain
We have setup postfix and dovecot so that clients can only use ssl/tls, and not starttls.
On thunderbird, we go to account settings / account actions / add mail account
We then enter the email address and password, and click on `configure manually`
Select SSL/TLS and normal password
For the server, thunderbird will incorrectly propose `.blog.reaction.la`
Put in the correct value, `rhocoin.org`, then click on re-test. Thunderbird will then correctly set the port numbers itself, which are the standard port numbers.
But the problem is, we might have an actual host running postfix, which wants to ask the host to which its MX record points, to send emails for it.
Configuring postfix as a satellite system just works, at least for emails generated by services running on the same machine, but postfix does not provide for it logging in. Instead, postfix assumes it has been somehow authorized, typically in `mynetworks` to relay.
Another way of setting it up, which I have not checked out, is [postfix_relaying_through_another_mailserver](https://www.howtoforge.com/postfix_relaying_through_another_mailserver){target="_blank"}
## Your ssh client
Your cloud server is going to keep timing you out and shutting you down,
so if using OpenSSH need to set up `~/.ssh/config` to read
```default
ForwardX11 yes
Protocol 2
TCPKeepAlive yes
ServerAliveInterval 10
```
Putty has this stuff in the connection configuration, not in the
config file. Which makes it easier to get wrong, rather than harder.
### A cloud server that does not shut you down
Your cloud server is probably virtual private server, a vps running on KVM, XEN,
or OpenVZ.
KVM is a real virtual private server, XEN is sort of almost a virtual
server, and OpenVZ is a jumped up guest account on someone else’s
server.
KVM vps is more expensive, because when they say you get 2048 meg,
you actually do get 2048 meg. OpenVZ will allocate up to 2048 gig if it
has some to spare – which it probably does not. So if you are running
OpenVZ you can, and these guys regularly do, put far too many virtual
private servers on one physical machine. Someone can have a 32 Gigabyte
bare metal server with eight cores, and then allocate one hundred virtual
servers each supposedly with two gigabytes and one core on it, while if he
is running KVM, he can only allocate as much ram as he actually has.
## Debian on the cloud
Debian is significantly more lightweight than Ubuntu, harder to
configure and use, will crash and burn if you connect up to a software
repository configured for Ubuntu in order to get the latest and greatest
software. You generally cannot get the latest and greatest software, and
if you try to do so, likely your system will die on its ass, or plunge
you into expert mode, where no one sufficiently expert can be found.
Furthermore, in the course of setting up Debian, highly likely to break
it irretrievably and have to restart from scratch. After each change,
reboot, and after each successful reboot, take a snapshot, so that you
do not have to reboot all the way from scratch.
But, running stuff that is supposed to run, which not always the latest and
greatest, is more stable and reliable than Ubuntu. Provided it boots up
successfully after you have done configuring, will likely go on booting up
reliably and not break for strange and unforeseeable reasons. Will only
break because you try to install or reconfigure software and somehow
screw up. Which you will do with great regularity.
On a small virtual server, Debian provides substantial advantages.
Go Debian with ssh and no GUI for servers, and Debian with lightdm
Mate for your laptop, so that your local environment is similar to your
server environment.
On any debian you need to run through the apt-get cycle till it stops
However, this memory leak detection is incompatible with wxWidgets,
which does its own memory leak detection.
And since you are going to spend a lot of time in the debugger, Windows
Visual Studio recommended as the main line of development. But, for
cross compilation, wxWidgets recommended.
Code::Blocks (wxSmith GUI developer) is one open source cross platform which
may be out of date.
wxSQLite3 incorporates SQLite3 into wxWidgets, also provides ChaCha20
Poly1305 encryption. There is also a wrapper that wraps SQLite3 into
modern (memory managed) C++.
wxSQLite3 is undergoing development right now, indicating that wxWidgets
and SQLite3 are undergoing development right now. `wxSmith` is dead
`Tk` is still live, but you get confusingly directed to the dead version.
## Model View Controller Architecture
This design pattern separates the UI program from the main program, which is
thus more environment independent and easier to move between different
operating systems.
The Model-view-controller design pattern makes sense with peers on the
server, and clients on the end user’s computer. But I am not sure it makes
sense in terms of where the power is. We want the power to be in the
client, where the secrets are.
Model
: The central component of the pattern. It is the application’s dynamic data
structure, independent of the user interface.[5] It directly manages the
data, logic and rules of the application.
View
: Any representation of information such as a chart, diagram or table.
Multiple views of the same information are possible, such as a bar chart for
management and a tabular view for accountants.
Controller
: Accepts input and converts it to commands for the model or view.
So, a common design pattern is to put as much of the code as possible into
the daemon, and as little into the gui.
Now it makes sense that the Daemon would be assembling and checking large
numbers of transactions, but the client has to be assembling and checking
the end user’s transaction, so this model looks like massive code
duplication.
If we follow the Model-View-Controller architecture then the Daemon provides
the model, and, on command, provides the model view to a system running on
the same hardware, the model view being a subset of the model that the view
knows how to depict to the end user. The GUI is View and Command, a
graphical program, which sends binary commands to the model.
Store the master secret and any valuable secrets in GUI, since wxWidgets
provides a secret storing mechanism. But the daemon needs to be able to run
on a headless server, so needs to store its own secrets – but these secrets
will be generated by and known to the master wallet, which can initialize a
new server to be identical to the first. Since the server can likely be
accessed by lots of people, we will make its secrets lower value.
We also write an (intentionally hard to use) command line view and command
line control, to act as prototypes for the graphical view and control, and
test beds for test instrumentation.
## CMake
CMake is the best cross platform build tool, but my experience is that it is
too painful to use, is not genuinely cross platform, and that useful projects
rely primarily on autotools to build on linux, and on Visual Studio to build
on Windows.
And since I rely primarily on a pile of libraries that rely primarily on
autotools on linux and Visual Studio on windows ...
## Windows, Git, Cmake, autotools and Mingw
Cmake in theory provides a universal build that will build stuff on both
Windows and linux, but when I tried using it, was a pain and created
extravagantly fragile and complicated makefiles.
Libsodium does not support CMake, but rather uses autotools on linux like
systems and visual studio project files on Windows systems.
wxWidgets in theory supports CMake, but I could not get it working, and most people use wxWidgets with autotools on linux like systems, and visual studio project files on Windows systems. Maybe they could not get it working either.
Far from being robustly environment agnostic and shielding you from the
unique characteristics of each environment, CMake seems to require a whole
lot of hand tuning to each particular build environment to do anything useful.
is to have the post-update hook turn it into a old plain dumb files, and
then put a symlink to your directory in the repository in your apache
directories, whereupon the clone command takes as its argument the
directory url (with no trailing backslash).
## Sharing git repositories
### Git Daemon
git-daemon will listen on port 9418. By default, it will allow access to any directory that looks like a git directory and contains the magic file git-daemon-export-ok.
This is by far the simplest and most direct way of allowing the world to get at your git repository.
### Gitweb
Does much the same thing has git-daemon, makes your repository public with a
prettier user interface, and somewhat less efficient protocol.
Gitweb provides a great deal of UI for viewing and interacting with your
repository, while git-daemon just allows people to clone it, and then they can
look at it.
### [gitolite](https://gitolite.com/gitolite/)
It seems that the lightweight way for small group cooperation on public
projects is Gitolite, git-daemon, and Gitweb.
Gitolite allows you to easily make people identified by their ssh public key
and the filename of the file containing their public key write capability to
certain branches and not others.
On Debian host `apt-get install gitolite3`, though someone complains this version is not up to date and you should install from github.
It then requests your public key, and you subsequently administer it through
the cloned repository `gitolite-admin` on your local machine.
It likes to start with a brand new empty git account, because it is going to
manage the authorized-keys file and it is going to construct the git
repositories.
Adding existing bare git repositories (and all git repositories it manages
have to be bare) is a little bit complex.
So, you give everyone working on the project their set of branches on your
repository,and they can do the same on their repositories.
This seems to be a far simpler and more lightweight solution than Phabricator
or Gitlab. It also respects Git’s inherently decentralized model. Phabricator
and Gitlab provide a great big pile of special purpose collaboration tools,
which Gitolite fails to provide, but you have to use those tools and not other tools. Gitolite seems to be overtaking Phabricator. KDE seems to abandoning Phabricator:
> The KDE project [uses](https://community.kde.org/Sysadmin/GitKdeOrgManual)
> gitolite (in combination with redmine for issue tracking and reviewboard for
> code review). Apart from the usual access control, the KDE folks are heavy
> users of the "ad hoc repo creation" features enabled by wildrepos and the
> accompanying commands. Several of the changes to the "admin defined
> commands" were also inspired by KDE’s needs. See
> [section 5](https://community.kde.org/Sysadmin/GitKdeOrgManual#Server-side_commands) and
> [section 6](https://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_repositories) of the above linked page for details.
So they are using three small tools, gitolite, redmine, and reviewboard,
instead of one big monolithic hightly integrated tool. Since we are creating a messaging system where messages can carry money and prove promises and
context, the eat-your-own dogfood principle suggests that pull requests and
code reviews should come over that messaging system.
Gitolite is designed around giving identified users controlled read and
write access, but [can provide world read access] through gitweb and git-daemon.
[can provide world read access]:https://gitolite.com/gitolite/gitweb-daemon#git-daemon
"gitweb and git-daemon – Gitolite"
### [Gitea] and [Gogs]
[Gitea]:https://gitea.io/en-us/
[Gogs]:https://gogs.io
"Gogs: A painless self-hosted Git service"
Gitea is the fork, and Gogs is abandonware. Installation seems a little
scary, but far less scary than Gitlab or Phabricator. Like Gitolite, it expects
an empty git user, and, unlike Gitolite, it expects a minimal ssh setup. If
you have several users with several existing keys, pain awaits.
It expects to run on lemp. [Install Lemp stack on Debian](#lemp-stack-on-debian)
It's default identity model is username/password/email, but it supports the
username/ssh/gpg user identity model. The user can, and should, enter an
ssh and gpg key under profile and settings / ssh gpg keys, and to
prevent the use of https/certificate authority as a backdoor, require
commits to be gpg signed by people listed as collaborators.
If email is enabled, password reset is by default enabled. Unfortunately
email password reset makes CA system the root of identity so we have to
disable it. We need to make gpg the root of identity, as a temporary
measure until our own, better, identity system is working.
It is development model is that anyone can fork a repository, then submit a pull request, which request is then handled by someone with authority to push to that repository.
gpg signatures should, of course, have a completely fake email address,
because the email address advertised in the gpg certificate will be
spammed and spearphished, rendering it useless. But gpg is completely
designed around being used with real email addresses. If you are using it
to sign, encrypt, and verify emails through its nice integration with the
thunderbird mail client, you have to use real email addresses.
Uploading a repository to Gitea is problematic, because it only accepts
repositories on other Gitea, Gog, Gitlab, and Github instances. So you have
to create a fresh empty repository on Gitea, set it to accept an ssh key
from your `.ssh/config`, and merge your existing repository into it.
Download the empty gitea repository. Make it even emptier than it already
is with `git rm`. Because the histories are unrelated, almost anything with
the same name will cause a merge conflict.
```bash
git rm *
git commit -am "preparing to merge into empty repository"
git push
```
Got to the real repository, and merge the empty gitea repository on top of it:
# The histories are no longer unrelated, so push will work.
```
We are doing this in the real repository, so that the original history remains
unchanged - we want the new empty gitea repository on top, not underneath.
Comes with password based membership utilities and web UI ready to
roll, unlike Gitolite which for all its power just declares all the key
management stuff that it is so deeply involved in out of scope with the result
that everyone rolls their own solution ad-hoc.
These involve fewer hosting headaches than the great weighty offerings of
GitLab and Phabricator. They can run on a raspberry pi, and are great ads for
the capability of the Go language.
Gitea, like Gitolite, likes to manage people’s ssh keys. You have to upload
your ssh and gpg public key as part of profile settings. Everything else, is
unfortunately, password based and email based, which is to say based on the
domain system and certificate authority system, which is an inherent massive
security hole, since the authorities can seize the website and put anything
on it they want. Therefore, need to use the [Gitea signing feature](
https://docs.gitea.io/en-us/signing/
"gpg Commit Signatures - Docs")
This seems to require Gitea to do a lot of signing, which is a gaping
security hole, though it can be used with the gpg feature allowing short
lived subkeys.
Will sign with subkey, because MasterKey should not be available on the server
### To set up a system with gpg subkeys but without the master key
This is horribly painful, and we need to create a better system and eat our
own dogfood.
We ignore the Gpg Web of Trust model and instead use the Zooko identity model.
We use Gpg signatures to verify that remote repository code is coming from an unchanging entity, not for Gpg Web of Trust. Web of Trust is too complicated and too user hostile to be workable or safe.
Never --sign any Gpg key. --lsign it.
Never use any public gpg key repository.
Never use any email address on a gpg key unless it is only used for messages relating to a single group and a single purpose, or a fake email.
Gpg fundamentally lacks the concept of one entity acting for and on behalf
of another. A subkey should be identified by the name of the master key
followed by a subname intelligible to humans, and a sequence of grant of
authority values intelligible to computers, represented by either a variable
precision integer representing a bit string, each bit corresponding to a an
authority value, which bitstring may contain a flag saying that further
authorities are represented by a null terminated Dewey decimal sequence rather
than by one bits in a sparse bitstring.
But for the moment:
```bash
gpg --expert --full-gen-key
```
Select 9 ECC and ECC, then select curve25519, then 0, key does not expire.
(This is going to be the rarely used master key, whose secret will be kept in
a safe place and seldom used)
Much open source cryptography has been backdoored. I have no reason to
suppose that gpg is backdoored, other than that there is a great deal of
backdooring going around, but I have positive reason to suppose that
curve25519 has *not* been backdoored in gpg, and even if I did not, the
fewer cryptographic algorithms we use, the smaller the attack surface.
Gitlab strongly recommends using only ED25519 ssh keys to interact with
git repositories, and I strongly recommend using only ED25519 ssh keys
to interact with repositories and only 25519 gpg keys to authenticate
commits and identify committers. I mention Gitlab not because I regard
them as a highly authoritative source, but to show I am not the only one
around who is paranoid about broken and corrupted cryptographic code.
Everyone should use the same algorithm to reduce the attack surface.
Name `«master key»>` (use a fake email address) Gpg was designed to
make email secure, but email is not secure. We will be using this as the
root of identities in Git, rather than to authenticate email. Use this root of
identity only for project related matters, only for the authentication of code
and design documents. Don't use this identity for other purposes, as this
will increase the risk that pressure or unpleasant consequences will be
applied to you through those other activities. Don't link this identity to
your broader identity and broader activities, as pressure is likely to applied
to introduce hostile code and strange design decisions that facilitate other
people's hostile code. This happens all the time in projects attempting to
implement cryptography. They get one funny feature after another whose
only utility is facilitating backdoors.
gpg will ask you for a passphrase. If your keyfile falls into enemy hands,
your secret key is subject to offline dictionary attack, against which only a
very strong passphrase, with about 128 bits of entropy, can protect it.
Which is a problem that crypto wallets address, and gpg fails to address.
Either use a strong non human memorable passphrase or else use a trivial
passphrase or no passphrase, and instead export and hide the secret key
file and delete it from gpg when you are done. A human cannot remember
a strong passphrase. Write it down, in pencil, and hide it somewhere.
(Pencil does not fade, but some inks fade) If you can remember the
passphrase, and someone gets at your keyfile, it is unlikely to protect you
keyfile. A strong passphrase looks like a wallet master secret.
Gpg's passphrases are merely a nuisance. They fail to serve a useful
purpose if used in the manner intended. Wallets came under real attack,
and now do things correctly. One of our objectives is to replace gpg for git
and gpg for secure messaging with something that actually works, with a
wallet, but for the moment, we use what we have.
Now create another similar subkey. This time give it an expiry date in the
near future
```bash
gpg --expert --edit-key «master key»
addkey
```
Rather than protecting your primary keys with a useless password, you
should export them to a safe place, such as a pair of thumbdrives, and then
delete them, to be re-imported when you need them to add a new subkey
Being written in PHP, assumes a Lamp stack, apache2, php 5.2 or later,
mysql 5.5 or later
Phabricator assumes and enforces a single truth, it throws away a lot of the
inherent decentralization of git. You always need to have one copy of
the database, which is the King – which people spontaneously do with git,
but with git it is spontaneous, and subject to change.
KDE seems to be moving away from Phabricator to Gitolite, but they have an
enormously complex system, written in house, for managing access, of which
Gitolite is part. Perhaps, Phabricator, being too big, and doing too much was
inflexible and got in their way.
Github clients spontaneously choose one git repository as the single truth, but then you have the problem thatGithub itself is likely to be hostile. An easy solution is to have the Github respository a clone of the remote repository, without write privileges.
### Gitlab repository
Git, like email, automatically works – provided that all users have ssh
login to the git user, but it is rather bare bones, better to fork out
the extra cash and support gitlab – but gitlab is far from automagic,
and expects one git address for git and one chat address for matterhorn,
and I assume expects an MX record also.
Gitlab is a gigantic memory hog, and needs absolute minimum of one core
and four gig, and two cores and eight gig strongly recommended for
anything except testing it out and toying with it. It will absolutely
crash and burn on less than four gig. If you are running gitlab, no cost
advantage to running it on debian. But for my own private vpn, huge cost
Every Linux desktop is different, and programs written for one desktop
have a tendency to die, mess up, or crash the desktop when running on
another Linux desktop.
Flatpack is a sandboxing environment designed to make every desktop
look to the program like the program’s native desktop (which for
wxWidgets is Gnome), and every program look to the desktop like a
program written for that particular desktop.
Flatpack simulates Gnome or KDE desktops to the program, and then translates
Gnome or KDE behaviour to whatever the actual desktop expects. To do this, it
requires some additional KDE configuration for Gnome desktop programs, and some
additional Gnome information for KDE desktop programs, and some additional
information to cover the other 101 desktops.
WxWidgets tries to make all desktops look alike to the programmer, and Flatpack
tries to make all desktops look alike to the program, but they cover different
aspects of program and desktop behaviour, so are both needed. Flatpack covers
interaction with launcher, the iconization, the install procedure, and stuff,
which wxWidgets does not cover.
Linux installs tend to be wildly idiosyncratic, and the installed program winds
up never being integrated with the desktop, and never updated.
Flatpack provides package management and automatic updates, all the way from the
git repository to the end user’s desktop, which wxWidgets cannot.
This is vital, since we want every wallet to talk the same language as every
other wallet.
Flatpack also makes all IPC look alike, so you can have your desktop program
talk to a service, and it will be talking gnome iPC on every linux.
Unfortunately Flatpack does all this by running programs inside a virtual
machine with a virtual file system, which denies the program access to the
real machine, and denies the real machine access to the program’s
environment. So the end user cannot easily do stuff like edit the program’s
config file, or copy bitcoin’s wallet file or list of blocks.
A program written for the real machine, but actually running in the emulated
flatpack environment, is going to not have the same behaviours. The programmer
has total control over the environment in which his program runs – which means
that the end user does not.
# Censorship resistant internet
## [My planned system](social_networking.html)
## Jitsi
Private video conferencing
[To set up a Jitsi meet server](andchad.net/jitsi)
## [Zeronet](https://zeronet.io/docs)
Namecoin plus bittorrent based websites. Allows dynamic content.
Not compatible with wordpress or phabricator. Have to write your own dynamic site in python and coffescript.
## [Bitmessage](https://wiki.bitmessage.org/)
Messaging system, email replacement, with proof of work and hidden servers.
Non instant text messages. Everyone receives all messages in a stream, but only the intended recipients can read them, making tracing impossible, hence no need to hide one’s IP. Proof of work requires a lot of work, to prevent streams from being spammed.
Not much work has been done on this project recently, though development and maintenance continues in a desultory fashion.
# Tcl Tk
An absolutely brilliant and ingenious language for producing cross
platform UI. Unfortunately I looked at a website that was kept around for
historical reasons, and concluded that development had stopped twenty years ago.
In fact development continues, and it is very popular, but being absolutely
typeless (everything is a conceptually a string, including running code)
any large program becomes impossible for multiple people to work on.
Best suited for relatively small programs that hastily glue stuff together - it
is, more or less, a better bash, capable of running on any desktop, and
