# Labtop - init ## Navigation Back to [[Nexus - Homelab]] Jump to [[Homelab - Labtop#Tasks & Change Log]] | [[Homelab - Labtop#5. Retrospective|Retro]] ## Labtop project overview and objectives ### 0. Overview >[! info] Purpose and Problem Statement >The purpose of this project is create a bare metal install of a Linux distribution on an old MacBook Air ([Model a1466](https://support.apple.com/en-la/111924)) for the purpose of creating a first [[Nexus - Homelab|homelab]] environment, do some basic system configurations, install Docker, and then run an instance of PostgreSQL from a docker container. #### 0.1 Learning Objectives and Goals >[! info] Learning Objectives > - [ ] How to install Linux on old hardware > - [ ] Troubleshooting the process > - [ ] Start documentation and writing about it. > - [ ] Terminal is stable and dotfiles documented in GH > - [ ] Able to SSH to the machine > - [ ] Break something and test Git Revert > - [ ] Create and publish a useful script (even if a million other people have done it already) > - [ ] Publish relevant files in GH and blog #### 0.2 Glossary for this project. Documented here are key words that I learn along the way. >[! cue] Key Terminology - [[Bare metal Linux]] | [[Bash]] - [[Classless Inter-Domain Routing|CIDR]] | [[Command Line Interface (CLI)]] | [[Container]] - [[Distro]] - [[Headless]] - [[Image]] | [[Infrastructure as Code]] - [[Kernel]] - [[Linux]] | [[Locale]] - [[Shell]] | [[SSH]] | [[systemctl]] - [[timedatectl]] #### 0.3 Conventions used I will follow the typical conventions noting code blocks in monospaced font. I will take the Luhman approach and write as if everything will be published (because it is.. its going online). I will also make use of Cornell note taking methods for the purpose of the logbook (this knowledge base) Sadly, I don't yet know how to configure the CSS class for Cornel styling to render on Obsidian Publish service. If anyone does know, then please email me. --- ### 1. Hardware As mentioned, the project is on an 11-year-old Apple MacBook Air. - MBA 2013, 13" - 1.7gHz dual-core i7 - 8gb ram (ddr3); max factory configurable - Storage 512GB; max factory configurable Though the SSD is upgradable to a max of 1TB, I will be only using the existing hardware to establish a proof of concept. --- ### 2. Linux Distro considerations. I think for my first attempts, I will follow some well documented procedures using some popular distributions of a linux server before venturing into Linux From Scratch (LFS) or Arch Linux installations. Translation: the first attempt will be to use Ubuntu Server [V24.04.1 LTS](https://ubuntu.com/download/server) My belief is that if the documentation is done properly, I should be able to extend this new knowledge to other installation projects with different levels of complexity. --- ### 3. Base Installation #### Preparation I knew I was going to need to create a bootable drive media to enable the OS installation. To do this, I followed best practices in downloading the ISO from the official repository, then flashing a USB drive device of sufficient size using [Balena Etcher](https://etcher.balena.io) software. Once the bootable media was created, I set about to log-out of apple services on the laptop and do a "factory reset" on the hard drive. Upon completing the factory reset, I was ready to initiate the installation of the server. #### Installation procedure There really isn't that much to note here. Following the onscreen directions was rather easy. My main decision point was deciding what to do in setting an IP address, giving the server a name, and deciding on my passphrase. I decided to set a static IP during the installation process. Since I am a beginner, I had no idea what CIDR was, and why the server needed to know it. I did, however, have some notion of IP addresses which served me ok in this process. I gave the machine a friendly name and completed the install. I really enjoyed the ease of which linux just installed on the machine. I also rather enjoy all the scrolling text during the boot sequence. All the services turning on and the flood of text is very soothing. --- ### 4. First steps. This section will broadly outline tasks that I completed as I moved from bare install to the first simple deployment. #### SSH testing. The key metric for success of the _labtop: init_ project is to perform an SSH and complete a few post-install tasks. - Standard SSH access via password from two client devices (two other laptops) was successful. #### OS Hygiene: Update&Upgrade Next I updated the OS from the base image and upgraded all the packages using [[APT]] using the commands `sudo apt update` and then `sudo apt upgrade` #### Time Zone Adjustment and `neofetch` Once completed, I then installed a program called `neofetch`, which gathers system information and outputs a pleasant graphic with system data. Here I noticed that my command line was giving the time in UTC rather than that of my locale. #### Shell, Terminal, and Prompt Configuration. The next section describes choices I made relating to how I interact with the server. ##### Bash Shell >[!cue] Bash I have chosen to migrate to [[Bash]] as my [[Shell]] on all my hardware since that is what is shipped on linux distributions. To do this, my local macos clients had to be reconfigured for the Bash due to their default being Z-Shell (ZSH). I am hoping that unifying the Shell across all my devices is helpful in an enterprise setting. ##### Ghostty Terminal >[!cue] [Ghostty](https://ghostty.org) My [[terminal emulator|terminal]] application that I have been using on my other devices is [[Ghostty]]. I am not a hype-follower, but I couldn't help but fall in love with the ethos of zero-config. A friend of mine who works as a professional data engineer once told me that I needed to think about all the customizations I am making to my terminal and prompt because if / when I switch to a new machine I would have a hard time because aliases and other cli tools may not be allowed. I think what was meant by that is that there are circumstances where I won't have access to a dotfile configuration and would need to rely on my foundational skills to navigate and perform tasks. Ghostty is so new, that although it works on the linux distro I have deployed, I get some issues with certain tools not being compatible because Ghostty's Terminfo is yet to be included in what ships with linux right now. This has had some impacts on SSH capability, using nano code editor on the command line and some other tools like `tree`. Luckily, there is a guide on what to expect and how to correct the matter. See [[Homelab - Labtop#15-FEB-2025|Change Log: 15-FEB]] for details. ##### Starship Prompt >[!cue] [Starship Cross-Shell Prompt](https://starship.rs) I do want some level of prompt customization primarily because I rather enjoy the look and feel of a well designed prompt that provides uncluttered information when I need it. Once the GitOps and Git repositories are set up, I should be able to deploy a custom prompt. _Custom prompt_ will probably be a pre-packaged theme because I am LAZY. However, heeding my friend's advice above, I might be better served by keeping track of the changes and being extremely intentional with any customizations made. I guess I have to find a good balance between customizations and minimal necessity. >[! warning] Descoped. >This portion of the project was descoped and pushed to [[Nexus - Homelab#Labtop Backlog|backlog]] #### SSH testing part II: Electric Boogaloo In a chat on the Skool platform, I learned that I could use SSH Key authentication for access into the server system. The upside of this is that now the access is based on Private/Public key pairs which greatly enhances the security on the system. The potential downside of this method is that I am still needing to manage key access on the server, and I need to keep my private keys safe on the client devices. There were some configuration files that needed to be adjusted in order to configure the server to only allow SSH Key access. The process in doing this highlights the **absolute need to practice GitOps** with this kind of adjustment, because I will forget. Or when the time comes for multiple notes, the configurations may differ or break. I want things to be easy. I want to document it, code it, and not have to worry about major roll-outs.... this calls to mind the meme One Does Not Simply... The management of SSHKey's might be a good topic for further investigation on another project. ### 5. Retrospective My top takeaway and opportunity from this project is that I need spend time to document or outline my project before executing the project tasks. I think I would have arrived at this step a lot sooner had I developed a (semi-)formal roadmap of what I want to do and how in a step-by-step fashion. I think a good practice would be to institute some project planning and documentation practices that I have learned about so far. Why? Well I care about velocity and quality of project completion. In this project, which I created on the 7th of this month, I only vaguely stated my goal and as a result I was all over the place once I got the first step done; Install Linux server and SSH into it. After that first step was taken, I kept adding and removing tasks at random then re-adding tasks. Executing a project in this way felt like I had no clear goal or indicator of when this project was _finished_. So, going forward, each new release of this project will have some kind of [[Project Charter]] or [[Scope of work (SOW)|scope of work]] document. Perhaps it doesn't need to be as rigid as a project charter but a description of the scope of work, key deliverables, timelines (optional), definition of ready, definition of done, something that I can use in the planning phase to prevent me from bolting on additional tasks and _side quests_. --- ## Tasks & Change Log ### Tasks >[!cue] Task list Below is the task list for the project. - [ ] SSH capability. - [ ] Update and Upgrade APT. - [ ] Investigate the time zone best practices for servers. The base install set to UTC - [[Locale]] [24 hour format Fix guide](https://askubuntu.com/questions/1238397/ubuntu-server-20-04-time-format-24-hours-on-shell-with-date-command#:~:text=To%20get%20date%20to%20display,only%20updates%20%2Fetc%2Flocale.) - [[timedatectl]], [TimeZone commandline line fix guide](https://askubuntu.com/questions/679988/how-to-change-ubuntus-server-date-and-time-via-command-line) - [ ] Configure [[Git]], and [[GitHub]] - [ ] `git config --global user.name` set - [ ] `git config --global user.email` set - [ ] SSH keys generated for server to GH, added passphrase. - [ ] Need to think about using Yubikey instead of passphrase. - [ ] Need to investigate if agent forwarding is useful for homelab usecase. - [ ] Resolve error `'xterm-ghostty': unknown terminal type.` - [ ] Done. Used walkthrough from [Ghostty Docs](https://ghostty.org/docs/help/terminfo) - [ ] Errors have resurfaced moving this issue out to TBD area. - [ ] Configure SSHKey access to server from local machines. - [ ] Retrospective & Celebrate! ### Change Log #### 17-FEB-2025 - Descoped tasks related to Git and Github - Descoped Starship entries. - Ghostty still buggy despite fix. The fix may not be persistent after server reboots. - Reverted home directory to a blank directory to prep for next project. - Drafted Retrospective #### 16-FEB-2025 - Configured SSHKey authentication on the server. - This means that local machines taht access the server directly via SSH will need to have SSH Keys generated and then provisioned on the server. - The process makes the home server a bit more secure in that no one can just guess my password now. - The following files were changed and I NEED TO GET A GIT REPO established so I don't need. - `/etc/ssh/` - `sshd_config` - `/etc/ssh/sshd_config/` - `50-cloud-init.conf` #### 15-FEB-2025 - GIT and GitHub configured and synced. - Using PARA Method on ~ directory. - `0_inbox` - `1_projects` - `2_aor` - `3_resources` - `4_archive` - learned [[mv]] command - Debugged local terminal [Ghostty](https://ghostty.org) - Solution walkthrough: [Ghostty Docs](https://ghostty.org/docs/help/terminfo) #### 14-FEB-2025 - Updated TimeZone via command line - [[timedatectl]], [TimeZone commandline line fix guide](https://askubuntu.com/questions/679988/how-to-change-ubuntus-server-date-and-time-via-command-line) - Updated time shown in date program to be 24 hour format. - Required updating `/etc/default/locale` file with new variable settings for a few locale variables. good write up from the the below stack exchange article - [[Locale]] [24 hour format Fix guide](https://askubuntu.com/questions/1238397/ubuntu-server-20-04-time-format-24-hours-on-shell-with-date-command#:~:text=To%20get%20date%20to%20display,only%20updates%20%2Fetc%2Flocale.) - Created two new entries for linux tools, `timedatectl` and `Locale` - Added task to automate this change in a dotfile repo on GH. - #### 11-FEB 2025 - Base install completed from boot media, ISO from Ubuntu website. - Post install basic APT update/upgrade. - New version: ==V.24.04.2LTS== - Installed `neofetch`, a system information tool for CLI. - [GH Repo](https://github.com/dylanaraps/neofetch) indicates that it is in `public archive` - The latest release is installed, released 2 Aug, 2020. - Installed via APT, the process installed many dependencies. - Shows CPU as quadcore... not a quadcore system. ... I think... ## Summary and takeaways >[! summary-top] The Labtop - Init project >Outcome: successful, v0.00 --> v0.01 >Highlight: It's ALIVE. >Opportunity: Better project planning ahead of time, to keep project tasks in scope and purpose driven. Use/adopt agile.