News

This is an old unmaintained mirror of my website, I have migrated to https://www.UnixTutorial.org as of Friday, May 1st 2020.

Please update your bookmarks and check out my YouTube channel: www.UnixTutorial.tv

See Also

• Project: from WordPress to Jekyll
• UnixTutorial.RU is using Jekyll now
• Jekyll 4 in macOS
• How To: Install Jekyll in Linux Mint
• Jekyll website with GitHub pages

Here are the articles and news I read in the past week or two – will roll them into the monthly Unix Tutorial Digest next time.

• You can't do GitOps until you can git add – article on getting started with managing your infrastructure as a code
• Basic Ansible playbooks by Michael W Lucas – helpful in my Ansible experiments with iptables and nftables
• Tails 4.4 Release summary on 9to5Linux
• Firefox 74 released
• Jekyll 4 Syntax Highlighting – I'm considering switching Unix Tutorial RU to Jekyll 4 as an experiment – need to get comfortable with features and extensions first
• Intro and Installation of Kubernetes

See Also

• Unix Tutorial Digest
• Unix Tutorial Digest – March 9th, 2020
• Interesting Links #1

It's taken me exactly two weeks to recognise the value of a native editor like Sublime Text 3 used for Ansible automation and Python scripting. I'm so impressed with the benefits brought by this approach that after another gentle reminder to perhpaps make the purchase already, I decided to hit the button.

WARNING: this is going to be a summary of my approach and view of local text editing on MacBook. HOWEVER, I just swiped something incorrectly and WordPress lost the whole post I've been typing up for about an hour. So I'll have to revisit and fill in the blanks later.

My Background with Text Editors

Why Not Just Use Editor in Remote Session?

Can't I use gVim or neoVim Instead?

Great Reasons to Use Native Editor

I'm listing things I enjoy specifically in Sublime Text 3 editing Ansible playbooks on my Macbook, but many modern editors bring similar improvements (unfairly) compared to out-of-the-box vim session on a typical Linux instance.

Functional Benefits of Editing Locally

• better view of file navigation – Sublime Text 3 has folder view on macOS and even highlights git status for all the files
• easier editing of multiple files with tabs – I like most apps with tabs in their interface, Sublime Text 3 definitely feels right with their approach. Tabs are easy to create and navigate, files are quick enough to be found using fuzzy search in filenames.
• great syntax highlighting, navigation and indentation – Sublime Text 3 shows the big preview of your whole text time in the right section of the window, gives you line numbers and shows how many spaces/tabs you have in each line – makes it much easier to tabulate
• bigger, more flexible access to source code and repos – your workstation can contain multiple projects and configuration files for various servers – you won't get this on individual servers and probably won't get it even on a dedicated automation server like Ansible/Puppet server – because they're usually dedicated to a client/project
• Quicker search in file and filesystem – I'm only learning how to use this properly in ST3, but there are plenty of ways to find something in a whole tree of directories pretty quickly
• Convenient access to plugins – this is definitely one of my favourites. In many companies you just don't get the same flexibility with installing software or plugins on any servers. You're at best discouraged from installing non-signed/downloaded from Internet (not originating from a signed software repo) softare. And you're completely blocked access at worst – firewall rules or AWS security groups need to be updated if you were to download anything directly on the server. Uploading plugin via scp is always an option, but many add-ons have dependencies which are a pain to resolve without readily availalbe Internet connection.

Quality Improvements in DevOps tasks

• less risk to break syntax in some config – you're comfortably editing, there are plugins checking and highlighting syntax, there may be commit hooks and peer reviews in your process to minimize risk
• automatically more global and generic thinking – because you're probably working on automation (Ansible) rather than actual config files, your mindset and your approach to solving an issue becomes more global. I notice that even when creating a playbook for just one server or VM, I'm already building it with scalability in mind – no hardcoded hostnames or functions, all the necessary flags and host specific variables. If time allows, I'm even implementing the same software install/configuration for both Debian and RedHat familiy of systems – just in case.
• better source code control – most of things I write locally will be automation or documentation, meaning they almost definitely end up on github. There's better history, better change trackign and more flexible way of rolling things back – all the usual improvements of using git
• definitely less temptation to mess around with any server directly – I have all the information, all the configs and templates here locally in my git repo. Logging in remotely to some server for fixing a problem becomes an extra step if not a hassle – and I like it this way, because this means my solution will be this bit more robust by the time I get to deploy

See Also

• Sublime Text 3
• Official Sublime Text 3 website
• Install Sublime Text in Linux

I have just started deploying my new VPS server online: vps1.unixtutorial.org

The idea is that I'll be hosting a number of VPS servers for us you learn Linux basics. vps1 is Ubuntu, future VPS servers will probably be CentOS and Amazon Linux 2 (hosted on AWS). All of these will be accessible on SSH (probably non-standard port) with shell access.

vps1.unixtutorial.org specs

• Location: Paris, Scaleway datacentre
• OS version: Ubuntu Bionic 18.04.2 LTS
• CPU: 2 vCPUs @ 2Ghz
• RAM: 2GB
• Disk: 20GB SSD (16GB available)

Here's how it looks:

Basic Unix Tutorial VPS rules

• you get standard user access with Bash shell
• no root access, but sudo can be provided for specific commands
• no Internet access (you can log in and run local commands, but can't download or upload anything from VPS server). no port forwarding .
• zero tolerance policy for hacking/exploit testing – if I notice any of you trying something like this, access will be revoked
• limited resource usage – please don't leave tasks running in background, etc.

Access to Unix Tutorial VPS servers

VPS access is completely FREE, but you need to become a Patreon for Unix Tutorial supporter or member of my Unix Tutorial group on Facebook. Please get in touch with me either via group or Patreon page regarding your username setup:

• preferred username (mine is greys)
• your full name (will be visible to other users of the VPS server)
• your email (so that I can email you the initial password)

Getting Help and Learning More

If you need guidance or mentorship with learning Linux, I provide some of this on the Active Learner membership level. If you want even more support or need specific lab setup learning a particular skill – this is possible with the Club Member level on Patreon.

See Also

• Hardware Lab for Unix Tutorial

Are you guys using Sublime Text 3?

Have heard and possibly even tried it before, wasn't impressed. But this time I'm doing Ansible playbooks and some light Python scripting development – and Sublime Text 3 is really growing on me.

Will be updating this post in the future, to list my settings and document plugins I decided to use.

See Also

• Sublime Text 3 website
• Unix Tutorial
• Advanced Unix Commands
• Ansible

Systemd had the goal of optimising startup times from the very beginning. It is therefore no particular wonder that it has a tool for precise startup timing and analysis: systemd-analyze.

Systemd Startup Analysis

Run without command line parameters, systemd-analyze shows a summary of how quickly your system booted Linux last time:

greys@srv:~ $ systemd-analyze
Startup finished in 2.743s (kernel) + 2.654s (userspace) = 5.397s
graphical.target reached after 2.641s in userspace

See What Systemd Service Took Longest to Start

It gets better! You can specify the blame parameter, and systemd-analyze will show you exactly how long each of the startup tasks has taken – that's really useful for troubleshooting:

greys@srv:~ $ systemd-analyze blame
           1.983s docker.service
            277ms certbot.service
            276ms man-db.service
            223ms dev-md0.device
            210ms apt-daily-upgrade.service
            208ms apt-daily.service
            194ms logrotate.service
            101ms systemd-fsck@dev-disk-by\x2duuid-cea13f85\x2d61fa\x2d414f\x2d9c2f\x2d1e48ec41ad25.service
             69ms chrony.service
             66ms systemd-journald.service
             61ms ssh.service
             59ms systemd-remount-fs.service
             57ms systemd-fsck@dev-disk-by\x2duuid-cfceff76\x2df739\x2d49e2\x2da4d1\x2d02472e5457f9.service
             46ms systemd-udev-trigger.service
             41ms keyboard-setup.service
             41ms systemd-logind.service
             40ms containerd.service
             36ms networking.service
             31ms apparmor.service
             27ms [email protected]
             21ms systemd-tmpfiles-setup.service
             21ms rsyslog.service
             19ms systemd-update-utmp.service
             15ms storage.mount
             14ms var-log.mount
             14ms systemd-udevd.service
             12ms dev-disk-by\x2duuid-799ad160\x2d8a59\x2d4c80\x2db78a\x2d7e3986876964.swap
             11ms systemd-user-sessions.service
             10ms dev-disk-by\x2duuid-261bd6ac\x2d2f4c\x2d475b\x2da4e4\x2db2548368e0fa.swap
             10ms systemd-update-utmp-runlevel.service
              9ms systemd-journal-flush.service
              9ms polkit.service
              9ms dev-disk-by\x2duuid-d45708da\x2d06f4\x2d41d6\x2daabe\x2decd87fb5edbe.swap
              8ms systemd-tmpfiles-clean.service
              8ms [email protected]
              7ms dev-mqueue.mount
              7ms sys-kernel-debug.mount
              7ms systemd-tmpfiles-setup-dev.service
              6ms systemd-modules-load.service
              6ms console-setup.service
              6ms systemd-sysusers.service
              4ms systemd-sysctl.service
              4ms kmod-static-nodes.service
              4ms dev-hugepages.mount
              4ms systemd-random-seed.service
              2ms ifupdown-pre.service
              1ms docker.socket
 greys@srv:~ $

See Also

• Systemd Reference (work in progress, available to my supporters on Patreon)
• Systemd Services Status
• journalctl – show systemd logs
• systemctl – manage systemd services
• systemd-analyze command