In the `[Seat:*]` section of the configuration file (there is another section of this configuration file where these changes have no apparent effect) edit
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.
To set things to autostart on gui login under Mate and KDE Plasma create
the directory `~/.config/autostart` and copy the appropriate `*.desktop`
files into it from `/usr/share/applications` or
`~/.local/share/applications`.
### Don't let the screen saver log you out.
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.
### setup ssh server
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.
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.
Setting them in `/etc/bash.bashrc` sets them for all users, including root. But the default `~/.bashrc` is apt to override the change of `H` for `h` in `PS1`
### fstab
The line for in fstab for optical disks needs to given the options `udf,iso9660 ro,users,auto,nofail` so that it automounts, and any user can eject it.
Confusingly, `nofail` means that it is allowed to fail, which of course it will
The same as for Debian, except that the desktop addition lacks openssh-server, it already has avahi-daemon to make the name available, and the install program will setup auto login for you.
OpenWrt is a router, and needs a network to route. So you use it to route a
virtual box internal network.
Ignore the instructions on the OpenWrt website for setting up in Virtual
Box. Those instructions are wrong and do not work. Kind of obvious that
they are not going to work, since they do not provide for connecting to an
internal network that would need its own router. They suffer from a basic
lack of direction, purpose, and intent.
Download the appropriate gzipped image file, expand it to an image file, and convert to a vdi file.
You need an [x86 64 bit version of OpenWrt](https://openwrt.org/docs/guide-user/installation/openwrt_x86). There are four versions of them, squashed and not squashed, efi and not efi. Not efi is more likely to work and not squashed is more likely to work, but only squashed supports automatic updates of the kernel.
Add the vdi to oracle media using the oracle media manager.
The resulting vdi file may have things wrong with it that would prevent it from booting, but viewing it in gparted will normalize it.
Create a virtual computer, name openwrt, type linux, version Linux 2.6, 3.x, 4.x, 5.x (64 bit) The first network adaptor in it should be internal, the second one should be NAT or bridged/
Boot up openwrt headless, and any virtual machine on the internal network should just work. From any virtual machine on the internal network, configure the router at http://192.168.1.1
## Virtual disks
The first virtual disk attached to a virtual machine is `/dev/sda`, the second
is `/dev/sdb`, and so on and so forth.
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
If you have a separate boot partition in an `efi `system then the `grub.cfg` in `/boot/efi/EFI/debian` (not to be confused with all the other `grub.cfgs`)
If you amend file system UUID's referenced in fstab and boot, have to amend `/etc/fstab` and `/boot/efi/EFI/debian/grub.cfg`, then rerun `update-grub`.
But a better solution is to change all the UUIDs, since every piece of software expects them to be unique, and edit `/etc/fstab` accordingly. Which will probably stop grub from booting your system, because in grub.cfg it is searching for the /boot or / by UUID.
However, sometimes one can add one additional virtual disk to a sata
controller after the system has powered up, which will produce no
surprises, for the disk will be attached but not mounted.
So cheerfully attaching one linux disk to another linux system so that you
can manipulate one system with the other may well have surprising,
unexpected, and highly undesirable results.
What decisions it has in fact made are revealed by `lsblk`
If one wants to add a several attached disks without surprises, then while
the virtual machines is powered down, attach the virtio-scsis controller,
and a bunch of virtual hard disks to it. The machine will then boot up with
only the sata disk mounted, as one would expect, but the disks attached to
the virtio controller will get attached as the ids /dev/sda, /dev/sdb,
/dev/sdc/, etc, while the sata disk gets mounted, but surprisingly gets the
last id, rather than the first.
After one does what is needful, power down and detach the hard disks, for
if a hard disk is attached to multiple systems, unpleasant suprises are
likely to ensue.
So when you attach a foreign linux disk by sata to another linux system,
attach after it has booted, and detach before you shutdown, to ensure
predictable and expected behavior.
This however only seems to work with efi sata drives, so one can only
attach one additional disk after it has booted.
Dynamic virtual disks in virtual box can be resized, and copied to a
different (larger size)
Confusingly, the documentation and the UI does not distinguish between
dynamic and fixed sized virtual disks - so the UI to change a fixed sized
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.
The filezilla client works natively on both windows and linux, and it is very good gui file copy utility that, like scp and rsync, works by ssh (once you set up the necessary public and private keys.) Unfortunately on windows, it insists on putty format private keys, while the git bash shell for windows wants linux format keys.
`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
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
## 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.
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
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.
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.
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)
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:
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.
ControlPort should be closed, so that only applications running on your computer can get to it.
DirPort and ORPort, if set, should be open -- whereupon you are running as a bridge.
Which you probably do not want, but are good for obfuscation traffic.
Because the cookie file is group readable,
applications running on your computer can read it to control tor through the control port.
It is a good idea to firewall this port so that it is externally closed, so that nothing
outside the computer can control tor.
DirPort and ORPort tell tor to advertise that these ports are open. Don't open or advertise them (set to zero), because then you are running as a bridge.
If you want to run as a bridge to create obfuscation:
```default
DirPort «your external ip address»:9030
ORPort «your external ip address»:9001
```
## installing tor browser
[Torproject on Github](https://torproject.github.io/manual/installation/){target="_blank"} provides information that actually works.
Download the tar file to your home directory, extract it, and execute the command as an ordinary user, no `sudo`, no root, no mucking around with `apt``
```bash
tar -xf tor-browser-linux-x86_64-13.0.8.tar.xz
cd tor-browser
./start-tor-browser.desktop --register-app
```
The next time you do a graphical login, tor will just be there
and will just work, with no fuss or drama. And it will itself
check for updates and nag you for them when needed.
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.
In the configuration file `nfs-common` change the paramter NEED_STATD to no and NEED_IDMAPD to yes. The NFSv4 required NEED_IDMAPD that will be used as the ID mapping daemon and provides functionality between the server and client.
```terminal_image
NEED_STATD="no"
NEED_IDMAPD="yes"
```
Then to disable nfs3 `sudo nano /etc/default/nfs-kernel-server`
```terminal_image
RPCNFSDOPTS="-N 2 -N 3"
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"
```
then to export the root of your nfs file system: `sudo nano /etc/exports`
