This commit is contained in:
reaction.la 2024-10-26 22:09:21 +00:00
parent 230b748a09
commit ec0e8650cb
No known key found for this signature in database
2 changed files with 117 additions and 117 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 24 KiB

View File

@ -136,7 +136,7 @@ m-a -qi prepare
apt autoremove -qy
mount /media/cdrom0
cd /media/cdrom0 && sh ./VBoxLinuxAdditions.run
usermod -a -G vboxsf cherry
usermod -a -G vboxsf «username»
```
You will need to do another `m-a prepare` and to reinstall it after a
@ -167,7 +167,7 @@ to
```ini
autologin-guest=false
autologin-user=cherry
autologin-user=«username»
autologin-user-timeout=0
```
@ -229,7 +229,7 @@ hostname && domainname -s && hostnamectl status
And if need be, set them with
```bash
fn=reaction.la
fn=«example.com»
domainname -b $fn
hostnamectl set-hostname $fn
```
@ -238,7 +238,7 @@ Your /etc/hosts file should contain
```text
127.0.0.1 localhost
127.0.0.1 reaction.la
127.0.0.1 «example.com»
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
@ -330,7 +330,7 @@ apt autoremove -qy
Then you click on the autorun.sh in the cdrom through the gui.
```bash
usermod -a -G vboxsf cherry
usermod -a -G vboxsf «username»
```
## Setting up OpenWrt in VirtualBox
@ -575,7 +575,7 @@ On an actual server, it is advisable to enable passwordless sudo for one user.
issue the command `visudo` and edit the sudoers file to contain the line:
``` default
cherry ALL=(ALL) NOPASSWD:ALL
«username» ALL=(ALL) NOPASSWD:ALL
```
That user can now sudo any root command, with no password login nor
@ -808,9 +808,9 @@ ssh-keygen -t ed25519 -f ssh_host_ed25519_key
(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
in `/home/«username»/.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
`/home/«username»/.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
@ -1106,7 +1106,7 @@ rsync -aAXvzP --delete remote_host:~/name .
To make sure the files are truly identical:
```bash
rsync -aAXvzc --delete reaction.la:~/name .
rsync -aAXvzc --delete «example.com»:~/name .
```
`rsync, ssh, git` and so forth know how to logon from the
@ -1208,7 +1208,7 @@ The sites-available directory looks like
```default
000-default.conf
reaction.la.conf
«example.com».conf
default-ssl.conf
```
@ -1216,37 +1216,37 @@ The sites enabled directory looks like
```default
000-default.conf -> ../sites-available/000-default.conf
reaction.la-le-ssl.conf
reaction.la.conf
«example.com»-le-ssl.conf
«example.com».conf
```
And the contents of reaction.la.conf are (before the https thingly has
And the contents of «example.com».conf are (before the https thingly has
worked its magic)
```default
<VirtualHost *:80>
ServerName reaction.la
ServerAlias www.reaction.la
ServerAlias «foo.reaction.la»
ServerAlias «bar.reaction.la»
ServerName «example.com»
ServerAlias www.«example.com»
ServerAlias «foo.«example.com»»
ServerAlias «bar.«example.com»»
ServerAdmin «me@mysite»
DocumentRoot /var/www/reaction.la
DocumentRoot /var/www/«example.com»
<Directory /var/www/reaction.la>
<Directory /var/www/«example.com»>
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
ErrorLog ${APACHE_LOG_DIR}/reaction.la-error.log
CustomLog ${APACHE_LOG_DIR}/reaction.la-access.log combined
ErrorLog ${APACHE_LOG_DIR}/«example.com»-error.log
CustomLog ${APACHE_LOG_DIR}/«example.com»-access.log combined
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.reaction.la\.com [NC]
RewriteRule ^(.*)$ https://reaction.la/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^www\.«example.com»\.com [NC]
RewriteRule ^(.*)$ https://«example.com»/$1 [L,R=301]
</VirtualHost>
```
All the other files dont matter. The conf file gets you to the named
server. The contents of /var/www/reaction.la are the html files, the
server. The contents of /var/www/«example.com» are the html files, the
important one being index.html.
[install certbot]:https://certbot.eff.org/instructions
@ -1265,31 +1265,31 @@ your nameservers, and only those names, certbot automagically converts
these from http virtual hosts to https virtual hosts and sets up
redirect from http to https.
If you have an alias server such as www.reaction.la for reaction.la,
certbot will guess you also have the domain name www.reaction.la and get
If you have an alias server such as www.«example.com» for «example.com»,
certbot will guess you also have the domain name www.«example.com» and get
a certificate for that.
Thus, after certbot has worked its magic, your conf file looks like
```default
<VirtualHost *:80>
ServerName reaction.la
ServerAlias foo.reaction.la
ServerAlias bar.reaction.la
ServerName «example.com»
ServerAlias foo.«example.com»
ServerAlias bar.«example.com»
ServerAdmin me@mysite
DocumentRoot /var/www/reaction.la
DocumentRoot /var/www/«example.com»
<Directory /var/www/reaction.la>
<Directory /var/www/«example.com»>
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
ErrorLog ${APACHE_LOG_DIR}/reaction.la-error.log
CustomLog ${APACHE_LOG_DIR}/reaction.la-access.log combined
ErrorLog ${APACHE_LOG_DIR}/«example.com»-error.log
CustomLog ${APACHE_LOG_DIR}/«example.com»-access.log combined
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://reaction.la/$1 [L,R=301]
RewriteCond %{SERVER_NAME} =reaction.la [OR]
RewriteRule ^(.*)$ https://«example.com»/$1 [L,R=301]
RewriteCond %{SERVER_NAME} =«example.com» [OR]
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
```
@ -1379,11 +1379,11 @@ when your site has your actual content on it.
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.
Create the directories `/var/www/«subdomain.example.com»` and `/var/www/«example.com»` and put some html files in them, substituting your actual domains for the example domains.
```bash
mkdir /var/www/reaction.la && nano /var/www/reaction.la/index.html
mkdir /var/www/blog.reaction.la && nano /var/www/blog.reaction.la/index.html
mkdir /var/www/«example.com» && nano /var/www/«example.com»/index.html
mkdir /var/www/«subdomain.example.com» && nano /var/www/«subdomain.example.com»/index.html
```
```default
@ -1392,7 +1392,7 @@ mkdir /var/www/blog.reaction.la && nano /var/www/blog.reaction.la/index.html
<head>
<meta charset="utf-8" />
</head>
<body><h1>reaction.la index file</h1></body>
<body><h1>«example.com» index file</h1></body>
</html>
```
@ -1400,7 +1400,7 @@ Delete the default in `/etc/nginx/sites-enabled`, and create a file, which I
arbitrarily name `config` that specifies how your domain names are to be
handled, and how php is to be executed for each domain names.
This config file assumes your domain is called `reaction.la` and your
This config file assumes your domain is called `«example.com»` and your
service is called `php-fpm.service`. Create the following config file,
substituting your actual domains for the example domains, and your actual
php fpm service for the fpm service.
@ -1416,14 +1416,14 @@ nano /etc/nginx/sites-enabled/config
```default
server {
return 301 $scheme://reaction.la$request_uri;
return 301 $scheme://«example.com»$request_uri;
}
server {
listen 80;
listen [::]:80;
index index.php index.html;
server_name blog.reaction.la;
root /var/www/blog.reaction.la;
server_name «subdomain.example.com»;
root /var/www/«subdomain.example.com»;
index index.php index.html;
location / {
try_files $uri $uri/ =404;
@ -1442,8 +1442,8 @@ server {
listen 80;
listen [::]:80;
index index.php index.html;
server_name reaction.la;
root /var/www/reaction.la;
server_name «example.com»;
root /var/www/«example.com»;
location / {
try_files $uri $uri/ =404;
}
@ -1458,8 +1458,8 @@ server {
}
}
server {
server_name *.blog.reaction.la;
return 301 $scheme://blog.reaction.la$request_uri;
server_name *.«subdomain.example.com»;
return 301 $scheme://«subdomain.example.com»$request_uri;
}
```
@ -1486,12 +1486,12 @@ www gets redirected.
Now we will create some php files in those directories to check that php works.
```bash
echo "<?php phpinfo(); ?>" |tee /var/www/reaction.la/info.php
echo "<?php phpinfo(); ?>" |tee /var/www/«example.com»/info.php
```
Then take a look at `info.php` in a browser.
If that works, then create the file `/var/www/reaction.la/index.php` containing:
If that works, then create the file `/var/www/«example.com»/index.php` containing:
```php
<?php
@ -1514,9 +1514,9 @@ If that works, then create the file `/var/www/reaction.la/index.php` containing:
?>
```
[http://reaction.la]:http://reaction.la
[http://«example.com»]:http://«example.com»
Browse to [http://reaction.la] If that works, delete the `info.php` file as it reveals private information. You now have domain names being served
Browse to [http://«example.com»] If that works, delete the `info.php` file as it reveals private information. You now have domain names being served
by lemp. Your database now is accessible over the internet through PHP
on those domain names.
@ -1604,7 +1604,7 @@ map to the old server, until the new server works.)
```bash
certbot register --register-unsafely-without-email --agree-tos
certbot run -a manual --preferred-challenges dns -i nginx \
-d reaction.la -d blog.reaction.la
-d «example.com» -d «subdomain.example.com»
nginx -t
```
@ -1646,11 +1646,11 @@ certbot renew --renew-by-default --http01
Because certbot automatically renews using the previous defaults, you
have to have previously used a process to obtain certificate suitable for
automation, which mean you have to have given it the information\
(`--webroot --webroot-path /var/www/reaction.la`)\
(`--webroot --webroot-path /var/www/«example.com»`)\
about how to do an automatic renewal by actually obtaining a certificate that way.
To backup and restore letsencrypt, to move your certificates from one
server to another, `rsync -HAvaX reaction.la:/etc/letsencrypt /etc`, as root
server to another, `rsync -HAvaX «example.com»:/etc/letsencrypt /etc`, as root
on the computer which will receive the backup. The letsencrypt directory
gets mangled by `tar`, `scp` and `sftp`.
@ -1667,12 +1667,12 @@ The certbot modified file for your ssl enabled domain should now look like
```default
server {
return 301 $scheme://reaction.la$request_uri;
return 301 $scheme://«example.com»$request_uri;
}
server {
index index.php index.html;
server_name blog.reaction.la;
root /var/www/blog.reaction.la;
server_name «subdomain.example.com»;
root /var/www/«subdomain.example.com»;
index index.php;
location / {
try_files $uri $uri/ =404;
@ -1688,15 +1688,15 @@ server {
}
listen [::]:443 ssl; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/reaction.la/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/reaction.la/privkey.pem; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/«example.com»/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/«example.com»/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
index index.html;
server_name reaction.la;
root /var/www/reaction.la;
server_name «example.com»;
root /var/www/«example.com»;
location / {
try_files $uri $uri/ =404;
}
@ -1711,35 +1711,35 @@ server {
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/reaction.la/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/reaction.la/privkey.pem; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/«example.com»/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/«example.com»/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name *.blog.reaction.la;
return 301 $scheme://blog.reaction.la$request_uri;
server_name *.«subdomain.example.com»;
return 301 $scheme://«subdomain.example.com»$request_uri;
}
server {
server_name *.reaction.la;
return 301 $scheme://reaction.la$request_uri;
server_name *.«example.com»;
return 301 $scheme://«example.com»$request_uri;
}
server {
if ($host = reaction.la) {
if ($host = «example.com») {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name reaction.la;
server_name «example.com»;
return 404; # managed by Certbot
}
server {
if ($host = blog.reaction.la) {
if ($host = «subdomain.example.com») {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name blog.reaction.la;
server_name «subdomain.example.com»;
return 404; # managed by Certbot
}
```
@ -1795,7 +1795,7 @@ mariadb
CREATE DATABASE wordpress DEFAULT CHARACTER SET
utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL ON wordpress.* TO 'wordpress_user'@'localhost'
IDENTIFIED BY 'FGikkdfj3878';
IDENTIFIED BY '«password»';
FLUSH PRIVILEGES;
exit
```
@ -1824,11 +1824,11 @@ cd temp
curl -LO https://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
cp -v wordpress/wp-config-sample.php wordpress/wp-config.php
cp -av wordpress/* /var/www/blog.reaction.la
chown -R www-data:www-data /var/www/blog.reaction.la && find /var/www -type d -exec chmod 755 {} \; && find /var/www -type f -exec chmod 644 {} \;
cp -av wordpress/* /var/www/«subdomain.example.com»
chown -R www-data:www-data /var/www/«subdomain.example.com» && find /var/www -type d -exec chmod 755 {} \; && find /var/www -type f -exec chmod 644 {} \;
# so that wordpress can write to the directory
curl -s https://api.wordpress.org/secret-key/1.1/salt/
nano /var/www/blog.reaction.la/wp-config.php
nano /var/www/«subdomain.example.com»/wp-config.php
```
Replace the defines that are there\
@ -1845,7 +1845,7 @@ define('DB_NAME', 'wordpress');
/** MySQL database username */
define('DB_USER', 'wordpress_user');
/** MySQL database password */
define('DB_PASSWORD', 'FGikkdfj3878');
define('DB_PASSWORD', '«password»');
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );
/** Database Charset to use in creating database tables. */
@ -1878,7 +1878,7 @@ mdir temp && cd temp
fn=blogdb
db=wordpress
dbuser=wordpress_user
dbpass=FGikkdfj3878
dbpass=«password»
mysqldump -u $dbuser --password=$dbpass $db > $fn.sql
head -n 30 $fn.sql
zip $fn.sql.zip $fn.sql
@ -1896,7 +1896,7 @@ Copy everything from the web server source directory of the previous
wordpress installation to the web server of the new wordpress installation.
```bash
chown -R www-data:www-data /var/www/blog.reaction.la
chown -R www-data:www-data /var/www/«subdomain.example.com»
```
Replace the defines for `DB_NAME`, `DB_USER`, and `DB_PASSWORD` in `wp_config.php`, as described in [Wordpress on Lemp]
@ -1914,7 +1914,7 @@ mariadb
DROP DATABASE IF EXISTS wordpress;
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8;
GRANT ALL ON wordpress.* TO 'wordpress_user'@'localhost'
IDENTIFIED BY 'FGikkdfj3878';
IDENTIFIED BY '«password»';
exit
```
@ -1936,7 +1936,7 @@ tar -xvf wordpress.sql.zst
fn=wordpress
db=wordpress
dbuser=wordpress_user
dbpass=FGikkdfj3878
dbpass=«password»
mariadb -u $dbuser --password=$dbpass $db < $fn.sql
mariadb -u $dbuser --password=$dbpass $db
```
@ -1996,11 +1996,11 @@ Then edit the virtual servers to be logged, which are in the directory `/etc/ngi
```text
server {
server_name reaction.la;
root /var/www/reaction.la;
server_name «example.com»;
root /var/www/«example.com»;
access_log /var/log/nginx/reaction.la.access.log;
error_log /var/log/nginx/reaction.la.error.log;
access_log /var/log/nginx/«example.com».access.log;
error_log /var/log/nginx/«example.com».error.log;
}
```
@ -2080,7 +2080,7 @@ obscurely connected to the configuration of each of the other things.
### Setting DNS entries for email
An MX record for `reaction.la` will read simply `mail` (no full stop, that
An MX record for `«example.com»` will read simply `mail` (no full stop, that
is for the case that you are trying to have a totally unrelated host handle
your mail) Check that it is working by using an MX lookup service such
as [MX tools] and [Dig]
@ -2154,8 +2154,8 @@ 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
`«example.com»` will always and only come senders like
`user@«example.com»`. 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,
@ -2286,7 +2286,7 @@ 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`
login as root, so you cannot easily access emails that wind up as `root@mail.«example.com»`
Probably you should create a user `postmaster`
@ -2411,8 +2411,8 @@ Modify `/etc/postfix/main.cf` using the postconf command:
# SMTP from other servers to yours
# Make sure to substitute your certificates in for the smtp
# and smtpd certificates.
postconf -e smtpd_tls_cert_file=/etc/letsencrypt/live/rhocoin.org/fullchain.pem
postconf -e smtpd_tls_key_file=/etc/letsencrypt/live/rhocoin.org/privkey.pem
postconf -e smtpd_tls_cert_file=/etc/letsencrypt/live/«example.com»/fullchain.pem
postconf -e smtpd_tls_key_file=/etc/letsencrypt/live/«example.com»/privkey.pem
postconf -e smtpd_tls_security_level = may
postconf -e smtpd_tls_auth_only = yes
postconf -e smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1, !TLSv1.1
@ -2424,8 +2424,8 @@ postconf smtpd_tls_session_cache_database
# smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
#
# SMTP from your server to others
postconf -e smtp_tls_cert_file=/etc/letsencrypt/live/rhocoin.org/fullchain.pem
postconf -e smtp_tls_key_file=/etc/letsencrypt/live/rhocoin.org/privkey.pem
postconf -e smtp_tls_cert_file=/etc/letsencrypt/live/«example.com»/fullchain.pem
postconf -e smtp_tls_key_file=/etc/letsencrypt/live/«example.com»/privkey.pem
postconf -e smtp_tls_security_level=may
postconf -e smtp_tls_note_starttls_offer=yes
postconf -e smtp_tls_mandatory_protocols='!SSLv2, !SSLv3, !TLSv1, !TLSv1.1'
@ -2456,20 +2456,20 @@ cat /var/log/mail.log |grep TLS
You should now see some TLS activity for those emails, and you should receive the emails.
OK, now we are all done, unless you want people to send you emails at
cherry@rhocoin.org, and to be actually able to usefully read those emails
«username»@«example.com», and to be actually able to usefully read those emails
without setting up forwarding to another address.
Well, not quite done, for now that you can receive emails, need to add your email to to your DMARC policy.\
`v=DMARC1; p=quarantine; rua=mailto:postmaster@rhocoin.org`
`v=DMARC1; p=quarantine; rua=mailto:postmaster@«example.com»`
A dmarc record is a text record with the hostname `_dmarc`, and the policy is its text value.
### SASL
At this point any random person on the internet can send mail to
`root@rhocoin.org`, and you can automatically forward it to an actually
`root@«example.com»`, and you can automatically forward it to an actually
usable email address, but you cannot access his email account at
`root@rhocoin.org` from a laptop using thunderbird, and accessing it
`root@«example.com»` from a laptop using thunderbird, and accessing it
through the command line using `mail` is not very useful.
Because although Postfix by default accepts sasl authenticated mail
@ -2482,11 +2482,11 @@ smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_una
It has yet as yet nothing configured to provide `sasl` authentication.
We don't want random spammer on the internet to send email as
`random@rhocoin.org`, but we do want authenticated users to be able to do
`random@«example.com»`, but we do want authenticated users to be able to do
as they please.
So, need to install and configure Dovecot to provide sasl, to authenticate
cherry to Postfix. And need to tell Postfix to accept Dovecot authentication.
«username» to Postfix. And need to tell Postfix to accept Dovecot authentication.
However, before we do any of that, there is a very big problem, that all
email systems that allow clients to send email are a bleeding security hole,
@ -2585,19 +2585,19 @@ For each domain name that has an MX record pointing at this host add the
```bash
postconf virtual_alias_domains
postconf -e virtual_alias_domains=reaction.la,blog.reaction.la
postconf -e virtual_alias_domains=«example.com»,«subdomain.example.com»
postconf -e virtual_alias_maps=hash:/etc/postfix/virtual
```
Now create the file `/etc/postfix/virtual` which will list all the email addresses of users with email addresses ending in those domain names.
```default
ann@reaction.la ann
bob@reaction.la bob
carol@blog.reaction.la carol
dan@blog.reaction.la dan
@reaction.la blackhole
@blog.reaction.la blackhole
ann@«example.com» ann
bob@«example.com» bob
carol@«subdomain.example.com» carol
dan@«subdomain.example.com» dan
@«example.com» blackhole
@«subdomain.example.com» blackhole
# ann, bob, carol, dan, and blackhole have to be actual users
# on the actual host, or entries in its aliases file, even if there
# is no way for them to actually login except through an
@ -2627,9 +2627,9 @@ 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`
For the server, thunderbird will incorrectly propose `.«subdomain.example.com»`
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.
Put in the correct value, `«example.com»`, then click on re-test. Thunderbird will then correctly set the port numbers itself, which are the standard port numbers.
[tutorial](https://www.linux.com/training-tutorials/how-set-virtual-domains-and-virtual-users-postfix/)
@ -2955,7 +2955,7 @@ To set up Git on the cloud,
and to use git on the cloud
[see](http://blog.davidecoppola.com/2016/12/how-to-set-up-a-git-repository-locally-and-on-a-remote-server/).
On my system, I ssh into the remote system `reaction.la` as the user
On my system, I ssh into the remote system `«example.com»` as the user
`git` and then in the `git` home directory:
```bash
@ -2973,7 +2973,7 @@ git init
git add *
git commit -m"this is a project to so and so"
git remote -v
git remote add origin git@reaction.la:~/MyProject
git remote add origin git@«example.com»:~/MyProject
git remote -v
git push -u origin --all # pushes up the repo and its refs for the first time
git push -u origin --tags
@ -2993,8 +2993,8 @@ their public key with the putty key gen copy and paste public key.
Make sure the config file `~/.ssh/config` contains
Host reaction.la
HostName reaction.la
Host «example.com»
HostName «example.com»
Port 22
IdentityFile ~/.ssh/id_ed25519
@ -3389,8 +3389,8 @@ to hppts governed by a lets encrypt certificate.
[GitLab
Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/#getting-started)
expects to run on its own virtual host. In your DNS you would then have
two entries pointing to the same machine, e.g. gitlab.reaction.la and
mattermost.reaction.la. GitLab Mattermost is disabled by default, to
two entries pointing to the same machine, e.g. gitlab.«example.com» and
mattermost.«example.com». GitLab Mattermost is disabled by default, to
enable it just put the external url in the configuration file.
Github, on the other hand, allows you to point [your own domain name to
@ -3456,7 +3456,7 @@ Eight gig, two cores, which you will need to run gitlab for everyone, is
Also, [vpn on the cloud](https://github.com/Nyr/openvpn-install).
Currency project should be [hosted on digital ocean at git.reaction.la, at
Currency project should be [hosted on digital ocean at git.«example.com», at
\$20 per month (Four gig, two cores), using Gitlab free omnibus
edition](ww.digitalocean.com/community/tutorials/how-to-use-the-gitlab-user-interface-to-manage-projects).
They suggest configuring your own Postfix email server on the machine
@ -3558,10 +3558,10 @@ $ cat ~/.local/share/applications/bitcoin.desktop
[Desktop Entry]
Type=Application
Name=Bitcoin
Exec=/home/cherry/bitcoin-22.0/bin/bitcoin-qt -min -chain=main
Exec=/home/«username»/bitcoin-22.0/bin/bitcoin-qt -min -chain=main
GenericName=Bitcoin core peer
Comment=Bitcoin core peer.
Icon=/home/cherry/bitcoin-22.0/bin/bitcoin-qt
Icon=/home/«username»/bitcoin-22.0/bin/bitcoin-qt
Categories=Office;Finance
Terminal=false
Keywords=bitcoin;crypto;blockchain;qwe;asd;
@ -3571,7 +3571,7 @@ cat ~/.config/autostart/bitcoin.desktop
[Desktop Entry]
Type=Application
Name=Bitcoin
Exec=/home/cherry/bitcoin-22.0/bin/bitcoin-qt -min -chain=main
Exec=/home/«username»/bitcoin-22.0/bin/bitcoin-qt -min -chain=main
Terminal=false
Hidden=false
```