RemoteShells
Summary
NOTE: This document is a work in progress.
This document describes the creation of a VPS for hosting liberty shell accounts on a remote machine from your main IRCNOW team server. The idea being that your users will login to and manage their publicly hosted content via their liberty shell account. The public hosting of data for your users will happen on your main IRCNOW team server. The specifics of how this works are described below.
Accounts hosted using this process will be able to function for a single user or as a group account with multiple sub accounts. The goal being to allow small groups to use a shell account to host a domain and website with email and xmpp accounts for each of their members. Each member will also have their own shell account and home directory as a sub-directory of the group account.
Shell Account Home Dirs
The home directory for the main shell account will contain the following structure:
configNow/etc configNow/var homes/ ikiwiki/ private/gitgot private/htdocs public/gitgot public/htdocs
Configuring via /etc/skel
These steps need to be confirmed.
mkdir -p /etc/skel/public/{gitgot, htdocs}
mkdir -p /etc/skel/private/{gitgot, htdocs}
mkdir -p /etc/skel/configNow/{etc,var}
mkdir -p /etc/skel/{homes,ikiwiki}
chmod -R 770 /etc/skel/{private,configNow}
Folder Descriptions
configNow
configNow is a system I am working on that will manage config file fragments needed for each account in the users home directory. These fragments will be used to generate the system config files needed for active users. The hope is this will make managing account specific configuration details easier. It will also provide the user with the ability to view and manipulate their configuration via the raw files. This poses a risk that it will be abused or the target of an attack so the system will be designed to detect recover from such abuse. I'm thinking a git repo of the compiled configuration should be maintained so its easy to identify the changes and revert to an earlier configuration if something breaks.
Simple config file ~/configNow/users.conf
#username:password hash user:$2%bpassword
This file will be read to generate the config files needed to create the sub accounts.
homes (user home directories)
Sub accounts will have home directories created inside ~/homes. Sub accounts will use the main shell account name as a prefix with hyphen between like this: shellname-username. Usernames can not exceed 31 characters. Sub accounts will use a home directory of /home/$shellname/homes/$username.
The following command will produce the desired shell accounts.
useradd -d /home/shellname/homes/username -g shellname -m shellname-username
public/private Shares.
The ~/public folder will be for public facing services. ~/private will be for public facing services that are behind a password interface. Details on ~/private are still being worked out; specifically we need to deploy an authentication mechanism for web services. The gitgot script is an example of how this process works for git/got repos. A similar script will be needed for each supported service.
Gitgot (public/private)
Gitgot is already a proven concept. This can be deployed behind a password protected website if stored in ~/private/gitgot. That hasn't been proven yet but shouldn't be too hard to make work.
htdocs (public/private)
The htdocs folders will be where users put their web content. A script will be needed to copy this to a staging area similar to how gitgot works. We should probably provide a way for static only sites to auto deploy while scripts need to be reviewed and approved. I'm thinking complex scripts like wordpress will require a vps to deploy but we could allow a simple web form to email type script to be run with approval type thing.
ikiwiki (CMS)
Ikiwiki is a wiki engine designed to use a software repository to store the content. This allows the data to be stored in the users shell account and deployed to the IRCNOW public server. Changes would be committed back to the users ikiwiki repo from the public server. More work is needed on the specifics of of this.
DNS Hosting
DNS hosting will be done on your main IRCNOW server. I'm thinking its best to use the same directory structure for zone files as opennsd uses. Users will be able to create zone files in ~/var/nsd/zones/master/. A script is needed to process user provided zone files. We'll need some sort of approval process for this I think. Don't want errors bringing down the server. We'll also want a web interface to allow users an easy interface for editing them. For now, a manual process will be needed requiring the user to notify us in irc or something.
eMail Hosting
I'm thinking we'll provide an interface for users to create multiple email accounts using the domain user@username.user.planetofnix.com or a custom domain if they have one. So Exile can have email accounts of support@exile.user.planetofnix.com type thing. If they registered a domain we can make that an alias to support@exile.org or whatever. Internally we should be able to configure email accounts to be support@exile for the login name.
Disk space may become an issue for email accounts but we can probably find a way to rent additional space for users that need it.
We will also need a process for managing and approving creation of accounts like this. I'm thinking just have the user create opensmtpd files as they would if they were running their own server and have them run a script to update the server. The user could then run a script to upload the files to a staging area and send admins an alert to review the changes before deploying them.
The hosting of the actual email accounts could be on the teams IRCNOW server, the teams user. server or a rented vps or third party server. I think the default configuration should be to host the mail accounts on the user. machine with the main IRCNOW server being configured as a backup/relay host for the mail server running on the user. host. If a user outgrows that we could move them to a full VPS or a third party as needed and still act as a backup/relay host for that if needed.
Basic Configuration
Follow the installation and base configuration documents for opensmtp and dovecot. Configure assuming a base name of user.teamname.tld. This will provide for configuration of accounts in the form of user@user.teamname.tld. This will work well for accounts for individuals, but not so good for groups that need individual email accounts.
Multi eMail accounts.
Its possible to host shell accounts with multiple email accounts. This is useful for say family email accounts, or employees in a small company, or developers on a project, etc. It is best to start with a Basic Configuration and confirm it is working before configuring to also handle multi email accounts.
This configuration extends the base configuration to also handle user@shellname.user.teamname.tld accounts. This requires adding an mx record for the shellname.user.teamname.tld domain that points to the mail.user.teamname.tld host. It is assumed you will be using your main teamname.tld for managing dns.
Configuring DNS
For a shell account to have multiple email addresses, you'll need to add an MX record to dns that points back to the main mail.user.teamname.tld server. To make life easier for auto configuration, you'll also want to configure CNAME records for mail, imap, pop, pop3, and smtp hostnames to pointing back to the user.teamname.tld equivalent names. Each new shellname will need lines like this added to /var/nsd/zones/master/user.teamname.tld
shellname 3600 IN MX 10 mail imap.shellname 3600 IN CNAME imap pop.shellname 3600 IN CNAME pop pop3.shellname 3600 IN CNAME pop3 smtp.shellname 3600 IN CNAME smtp mail.shellname 3600 IN CNAME mail
Configure smtpd
The following files need to be modified to add the new shellname.user.teamname.tld domain
# /etc/mail/domains shellname.user.teamname.tld # /etc/mail/mailname shellname.user.teamname.tld
Each user needs entries like the following added
# /etc/mail/virtual email1@shellname.user.teamname.tld vmail email2@shellname.user.teamname.tld vmail # /etc/mail/user email1@shellname.user.teamname.tld: email1@shellname.user.teamname.tld email2@shellname.user.teamname.tld: email2@shellname.user.teamname.tld # /etc/mail/passwd email1@shellname.user.teamname.tld:$2b$09$mjuUuQ4oIh7Ke/4h3kL6keLVKxlcxVIJ.Dw/Hva35KQ.YBLtUyETq::::::userdb_quota_rule=*:storage=1G email2@shellname.user.teamname.tld:$2b$09$mjuUuQ4oIh7Ke/4h3kL6keLVKxlcxVIJ.Dw/Hva35KQ.YBLtUyETq::::::userdb_quota_rule=*:storage=1G
Other Related services
Shadow email accounts
We should offer users the ability to create shadow email accounts that auto forward to sub folders. So you can create unique email boxes on the fly for tracking spam or auto filtering mail. The basic concept would be to use a user+code@ email address. Anything after the + sign would be a folder mail is auto filtered into.
eMail Encryption
Offering ways to manage email encryption would be a good idea here also.
XMPP Accounts
XMPP is a decentralised open source instant messenger protocol. Details on setting up the server can be found here https://wiki.ircnow.org/index.php?n=Openbsd.Prosody. These instructions cover the details needed to offer user@user.planetofnix.com accounts in addition to user@shellname.user.planetofnix.com accounts.
NOTE: Each account is considered unique in xmpp. There is no way to make one account an alias of another. The best you can do is have one account respond with a message directing the user to send messages to a different address. Accounts that also have a custom domain will technically have 3 individual account names available to them; Each would need to be activated using the prosodyctl tool.
DNS Entries
You need dns entries for your shellname so you can get a LetsEncrypt certificate and you need to point xmpp clients and servers to your xmpp server. Your entries will look something like this:
shellname 3600 IN A 38.87.162.191
3600 IN AAAA 2602:fccf:1:1191::
_xmpp-client._tcp.shellname 3600 IN SRV 0 5 5222 xmpp
_xmpp-server._tcp.shellname 3600 IN SRV 0 5 5269 xmpp
Lets Encrypt Certificate
vim /etc/acme-client.conf
domain shellname.user.planetofnix.com {
domain key "/etc/ssl/private/shellname.user.planetofnix.com.key"
domain full chain certificate "/etc/ssl/shellname.user.planetofnix.com.fullchain.pem"
sign with letsencrypt
}
These cert need to be copied to the /etc/prosody/certs dir and ownership changed.
cp /etc/ssl/shellname.user.planetofnix.com.* /etc/prosody/certs/ chown _prosody._prosody /etc/prosody/certs/shellname.*
Configure virtual domain
vim /etc/prosody/prosody.conf.lua
VirtualHost "shellname.user.planetofnix.com"
ssl = {
certificate = "/etc/prosody/certs/shellname.user.planetofnix.com.fullchain.pem";
key = "/etc/prosody/certs/shellname.user.planetofnix.com.key";
}
Account creation
prosodyctl adduser username@shellname.user.planetofnix.com prosodyctl passwd username@shellname.user.planetofnix.com