This is the fourth of a series on taking up residence on a new server. In our last post we talked about how to set up some basic network services like
ssh and configure
iptables, our firewall. In this post we'll talk about making your server feel like home.
There are a grand number of things we can do at this point to make our time on the machine enjoyable. Take time to evaluate your choices though. This 'root' host is going to be our 'control seat' so it's not going to be doing much more than orcestrating virtualized environments. Once we configure these environments (next post) we'll be using these for any sort of development, deployment, or experiments.
With 'root' our goal is to make a simple set of good, sharp tools to do what we need to do. These are tools like
nvim which we installed earlier. If you were following the last host you may have installed
mosh as well, which makes our
ssh sessions safe from network changes and comfortable against latency.
After installing a few more tools we'll discuss configuration of our tools while we overview their functionality and purposes.
Aside: The User Skeleton
/etc/skel you can find the file structure created for a new user. If a user
hoverbear is created then everything in
/etc/skel is copied into
/home/hoverbear (or wherever that user's home directory is).
On our 'root' we won't be utilizing this, since we will be the only users (your user and root which is also you). Instead we'll just be modifying the system-wide defaults, this way if we end up acting as the
root user or something we'll still have the same configuration.
The prompt you've been typing all these commands at is your shell. There are lots of different shells, this one is
bash. I've enjoyed using
fish before as well. Since this is our 'root' we're just going to stick with the built-in defaults, we can choose a fancy shell to load with lots of sketchy plugins in our less privileged container!
bash looks for configuration in
/etc/bash.bashrc which is overridden by
~/.bashrc. We'll remove these user specific files then edit the system-wide file.
Below I've included a commented configuration to explain many settings.
# # /etc/bash.bashrc # # If not running interactively, don't do anything. && # Use extra globing features. See man bash, search extglob. # Include .files when globbing. # When a glob expands to nothing, make it an empty string instead of the literal characters. # A command name that is the name of a directory is executed as if it were the argument to the cd command. # Let bash update the window size if we resize it. # This is what you see between every command. # Make your own at http://bashrcgenerator.com/ PS1="\[\033[38;5;10m\]\u\[ \]\[\033[38;5;7m\]@\[ \]\[\033[38;5;9m\]\H\[ \]\[\033[38;5;12m\]\w\[ \]\[\033[38;5;3m\] \[\033[38;5;15m\]\[ \]\$?\[ \] \n\[ \]\[\033[38;5;7m\]\t\[ \]\[\033[38;5;15m\] \[ \]\\$\[ \] " # The rest can really just be left default. PS2='> ' PS3='> ' PS4='+ ' # Set up bash completion. [ && # This tells grep to use color when appropriate. # Configures the default editor, we installed nvim earlier. # Get colors in ls by default
Now test it out by running
bash, your prompt should change. If it looks good
exit again and reconnect. This configuration is by no means exotic or impressive, it's just some nice basics.
The prompt is intended to clearly communicate where, and who, you are, as well as the exit code. Time can sometimes be useful, so I included it as well. It's all also nicely color coded. Here's how it's structured:
firstname.lastname@example.org/current/directory (system state) (last exit code) (time) $
(system state) refers to the output of
systemctl is-system-running which will output based on this list. In most cases it will either be
running if everything is good, or
degraded if some service has failed.
(last exit code) will be
0 if the last command exited successfully, and a different number if it did not.
Shell multiplexing is a great way to maintain a workspace on a remote machine. The idea is to have a daemon which holds onto your shell sessions for you and essentially acts as a 'window manager' for your various shell panes. You're then able to 'detach' and 'reattach' to these sessions whenever you want.
I'm aware of
screen which both accomplish this quite well. I prefer
tmux and we'll talk about setting up that one. You can find the wiki documentation here. You can get it with pacman:
The global configuration for
tmux lives at
/etc/tmux.conf and we can just configure a couple settings:
# Use a 256 color configuration. # Start windows and panes at 1, not 0. # So the history doesn't go on forever. # Split panes using | and -, this makes more sense! # Don't rename windows automatically. Rename with Ctl+B followed by , ### # Theme below. ### # Panes # Messaging # Window mode # Window status # Info on left # Modes # The statusbar
tmux you can create new 'tabs' with
Ctl+b c (press
b, then let go and press
c). You can rename them with
Ctl+b ,. You can split them with
Ctl+- respectively. You can move between splits with
Ctl+b left and
Ctl+b right. With
Ctl+b 1 or any number you can change 'tabs'.
You can detach
Ctl+b d and you can re-attach with
tmux a later on. Sessions will persist between logins but not between reboots.
Editing the Editor
Earlier we installed
pacman -S neovim. Neovim is a minimal modern recreation of
vim which itself was a recreation of
vi. There are also editors like
nvim systemwide configuration is stored at
/etc/xdg/nvim/init.vim, and you might need to create the folder with
mkdir -p /etc/xdg/nvim/.
Inside we can do some basic configuration:
" Be improved set nocompatible " General set number " Show line numbers set history=700 " Commands set autoread set magic " Regex related set showmatch " Brackets set mouse=a " Enable all mouse interaction. filetype plugin on syntax enable set ttyfast " Improve smoothness set lazyredraw " Don't redraw while executing macros set showcmd " Show partially typed commands at the bottom set wrap " Soft wrap lines " Indents set expandtab set smarttab set shiftwidth=4 set tabstop=4 set ai " Auto Indent set si " Smart Indent " Peace and quiet " (Side note: Vim does a 'bell' very often) set noerrorbells set novisualbell " Searching set ignorecase set smartcase set hlsearch set incsearch " Don't do some legacy-related things like temporary swapfiles. set nobackup set nowb set noswapfile " Tell vim to remember certain things when we exit " '10 : marks will be remembered for up to 10 previously edited files " "100 : will save up to 100 lines for each register " :20 : up to 20 lines of command-line history will be remembered " % : saves and restores the buffer list " n... : where to save the viminfo files set viminfo='10,\"100,:20,%,n~/.viminfo " Automagically restore files we were editing to the line we were on. ) if line("'\"") <= line("$") normal! g`" return 1 endif endfunction augroup restoreLine autocmd! autocmd BufWinEnter * call RestoreLine() augroup END " Colorscheme colorscheme spacegrey
Now we need to fetch the colorscheme, Spacegrey.
At this point
nvim is quite capable of doing any task we might need of it. Triumph in this by telling the system you and it are officially in a relationship.
Since it's probably been a couple days since you started this process, it's also a good idea to update:
- Check the Arch Frontpage in case there is any news item you need to be aware of.
Before moving on it might be a good idea to make a snapshot of what we have so far, this way we can roll back. This is a very cool feature of BTRFS and one of the main reasons I use it. Since this is technically our
/ the process is a bit more involved than usual.
# First, mount the BTRFS volume somewhere plainly, no subvolume. # Create a read-only snapshot of `root` called `root-fresh`.
If you ever find yourself in a situation where you just need to restart all over again, this is a snapshot you can use so you don't have to re-do all your configuration and setup. You would just have to:
- Boot into recovery.
- Mount the filesystem with
mount -o compress=lzo /dev/sda /mnt/.
btrfs subvolume delete /mnt/root
btrfs subvolume snapshot /mnt/root-fresh /mnt/root
For now this will give you a way to return back to this exact point while we dork around with containers. You can also mount it (like the other subvolumes) and recover defaults in case something gets bungled in your current system.
In later posts we'll be discussing BTRFS more in regards to how it works with containers and backups.
Ready to Go
Try running our three configured programs as both
root and your
$USER, their configurations should be the same. Our system has been configured to act in a simple, usable manner and behave with little surprising behaivor. Below you can see it with
journalctl -f running.
What's perhaps most important to remember throughout this process is that you kept this system very clean. Next post we'll discuss using containers to construct virtual environments, which we can be much more messy with!